Re: peer to peer regression test proposal (was Re: QT controller on Vista: how to change volume?)
Shouldn't they have these tests in-house? Cheers, Luis. On 22 Oct 2007, at 23:51, Richard Gaskin wrote: Andre Garzia wrote: I have here a little proposal for the volunteers on this list. With every release of an OS or Revolution we have some things breaking. This is the nature of things, we can't change it but we can help fix it. What about we build a community regression test, some test stacks. Each volunteer or group of volunteer would build and mantain a little stack to test some subset of revolution. With each release and platform, they'd test it against the new thing and we could report back to runrev and web. I can host this and I can build the report thing and I volunteer to build the regression test for socket routines and libURL (which never breaks!) This way a small group can do some impact and help Bill at QC and RunRev team. Even if we can't test all of transcript and rev, if we test 40% if it, still we can guarantee that this 40% is working or broken which is nice anyway. A group of people could take care of QT controler and routines testing and quickly catch things such as this volume issue very fast. is this a good idea? I think it's a great idea, but unfortunately some tests like what's needed to see this QT error require manual work. So as long as there's a framework for both automated and manual tests it should be quite helpful. -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: peer to peer regression test proposal (was Re: QT controller on Vista: how to change volume?)
Well, in Brazil we say: he who has no dog, hunts with a cat if they don't have these tests, or if their tests are not complete enough, or even if they have it, nothing is stopping us from helping. There are two objectives with us creating such tests: 1) quickly detect bugs and be able to generate a reports that is useful to the runrev team, we can add to their tests. Testing is good. 2) quickly tell other developers what is not working and maybe provide workarounds while runrev team patches it. ok? Andre On 10/23/07, Luis [EMAIL PROTECTED] wrote: Shouldn't they have these tests in-house? Cheers, Luis. On 22 Oct 2007, at 23:51, Richard Gaskin wrote: Andre Garzia wrote: I have here a little proposal for the volunteers on this list. With every release of an OS or Revolution we have some things breaking. This is the nature of things, we can't change it but we can help fix it. What about we build a community regression test, some test stacks. Each volunteer or group of volunteer would build and mantain a little stack to test some subset of revolution. With each release and platform, they'd test it against the new thing and we could report back to runrev and web. I can host this and I can build the report thing and I volunteer to build the regression test for socket routines and libURL (which never breaks!) This way a small group can do some impact and help Bill at QC and RunRev team. Even if we can't test all of transcript and rev, if we test 40% if it, still we can guarantee that this 40% is working or broken which is nice anyway. A group of people could take care of QT controler and routines testing and quickly catch things such as this volume issue very fast. is this a good idea? I think it's a great idea, but unfortunately some tests like what's needed to see this QT error require manual work. So as long as there's a framework for both automated and manual tests it should be quite helpful. -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution -- http://www.andregarzia.com All We Do Is Code. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: peer to peer regression test proposal (was Re: QT controller on Vista: how to change volume?)
Hi Andre and all, Yes it's a good idea: I don't do it systematically but I could test all my tutorials with every new version: each one focuses on a specific aspect of Rev (even if there are many others :-) Le 21 oct. 07 à 21:28, Andre Garzia a écrit : I have here a little proposal for the volunteers on this list. With every release of an OS or Revolution we have some things breaking. This is the nature of things, we can't change it but we can help fix it. What about we build a community regression test, some test stacks. Each volunteer or group of volunteer would build and mantain a little stack to test some subset of revolution. With each release and platform, they'd test it against the new thing and we could report back to runrev and web. I can host this and I can build the report thing and I volunteer to build the regression test for socket routines and libURL (which never breaks!) This way a small group can do some impact and help Bill at QC and RunRev team. Even if we can't test all of transcript and rev, if we test 40% if it, still we can guarantee that this 40% is working or broken which is nice anyway. A group of people could take care of QT controler and routines testing and quickly catch things such as this volume issue very fast. is this a good idea? Best regards from Paris, Eric Chatonet. Plugins and tutorials for Revolution: http://www.sosmartsoftware.com/ Email: [EMAIL PROTECTED]/ ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: peer to peer regression test proposal (was Re: QT controller on Vista: how to change volume?)
Andre Garzia wrote: I have here a little proposal for the volunteers on this list. With every release of an OS or Revolution we have some things breaking. This is the nature of things, we can't change it but we can help fix it. What about we build a community regression test, some test stacks. Each volunteer or group of volunteer would build and mantain a little stack to test some subset of revolution. With each release and platform, they'd test it against the new thing and we could report back to runrev and web. I can host this and I can build the report thing and I volunteer to build the regression test for socket routines and libURL (which never breaks!) This way a small group can do some impact and help Bill at QC and RunRev team. Even if we can't test all of transcript and rev, if we test 40% if it, still we can guarantee that this 40% is working or broken which is nice anyway. A group of people could take care of QT controler and routines testing and quickly catch things such as this volume issue very fast. is this a good idea? I think it's a great idea, but unfortunately some tests like what's needed to see this QT error require manual work. So as long as there's a framework for both automated and manual tests it should be quite helpful. -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
peer to peer regression test proposal (was Re: QT controller on Vista: how to change volume?)
Hello Friends, I have here a little proposal for the volunteers on this list. With every release of an OS or Revolution we have some things breaking. This is the nature of things, we can't change it but we can help fix it. What about we build a community regression test, some test stacks. Each volunteer or group of volunteer would build and mantain a little stack to test some subset of revolution. With each release and platform, they'd test it against the new thing and we could report back to runrev and web. I can host this and I can build the report thing and I volunteer to build the regression test for socket routines and libURL (which never breaks!) This way a small group can do some impact and help Bill at QC and RunRev team. Even if we can't test all of transcript and rev, if we test 40% if it, still we can guarantee that this 40% is working or broken which is nice anyway. A group of people could take care of QT controler and routines testing and quickly catch things such as this volume issue very fast. is this a good idea? andre ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: peer to peer regression test proposal (was Re: QT controller on Vista: how to change volume?)
On Sun, 21 Oct 2007 16:28:36 -0300, Andre Garzia wrote: A group of people could take care of QT controler and routines testing and quickly catch things such as this volume issue very fast. is this a good idea? Sounds good to me... count me in! Ken ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: peer to peer regression test proposal (was Re: QT controller on Vista: how to change volume?)
I can help, if there's need, but i need to be told what to do... If there's need for discussion, chatrev is open, as always... On 21 Oct 2007, at 21:28, Andre Garzia wrote: ... This way a small group can do some impact and help Bill at QC and RunRev team. Even if we can't test all of transcript and rev, if we test 40% if it, still we can guarantee that this 40% is working or broken which is nice anyway. A group of people could take care of QT controler and routines testing and quickly catch things such as this volume issue very fast. is this a good idea? -- official ChatRev page: http://chatrev.bjoernke.com Chat with other RunRev developers: go stack URL http://homepage.mac.com/bvg/chatrev1.3.rev; ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: peer to peer regression test proposal (was Re: QT controller on Vista: how to change volume?)
I'd certainly up for this...count me in! Best, Mark On 21 Oct 2007, at 21:28, Andre Garzia wrote: Hello Friends, I have here a little proposal for the volunteers on this list. With every release of an OS or Revolution we have some things breaking. This is the nature of things, we can't change it but we can help fix it. What about we build a community regression test, some test stacks. Each volunteer or group of volunteer would build and mantain a little stack to test some subset of revolution. With each release and platform, they'd test it against the new thing and we could report back to runrev and web. I can host this and I can build the report thing and I volunteer to build the regression test for socket routines and libURL (which never breaks!) This way a small group can do some impact and help Bill at QC and RunRev team. Even if we can't test all of transcript and rev, if we test 40% if it, still we can guarantee that this 40% is working or broken which is nice anyway. A group of people could take care of QT controler and routines testing and quickly catch things such as this volume issue very fast. is this a good idea? andre ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
