absolutely quim,<br>I felt nervous being able to push the first release
of liqbase from -devel to extras all on my own, I initially thought
back then these ^^^^ steps being discussed now were already in place
and that I couldnt promote my own package.<br>
<br>i do think there should be the flexibility of a fastrack for
security/serious bugfix push because the principle package has already
had the majority of the work done and already spent time in serious
testing, it will just be something to play by ear, different packages
effect systems in different and inventive ways (reminded of such with
my playtest)<br><font color="#888888">
<br>gary</font><br><br><div class="gmail_quote">On Mon, May 11, 2009 at 3:13 PM, Quim Gil <span dir="ltr"><<a href="mailto:quim.gil@nokia.com">quim.gil@nokia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
<br>
ext gary liquid wrote:<br>
> automated unit testing will not find all bugs or problems in perfectly<br>
> packages software.<br>
> manual human testing will not find all bugs or problems in perfectly<br>
> packaged software.<br>
><br>
> a combination of both involving common sense and prior history should<br>
> minimize the risk of problems though.<br>
<br>
</div>... and this is exactly what I proposed!<br>
<br>
1. Developer pushes packages from extras-devel to extras testing.<br>
<br>
2. Automated testing does the checks.<br>
<br>
2a. If the test fails, the packages don't get to extras-testing.<br>
<br>
2b. If the test is successful, the packages go to extras testing.<br>
<br>
3. In extras-testing the betatesters put the software into stress,<br>
equipped with Nitro (crash reporter installed in their devices) plus<br>
whatever tools they can use voluntarily.<br>
<br>
3a. If they find severe bugs the packages go back to extras devel.<br>
<br>
3b. If nobody finds a showstopper the app goes to extras after N weeks<br>
and N votes.<br>
<br>
I see the point of asking for qualified humans giving the green light as<br>
something more trustworthy than community testers rating. The problem I<br>
see is that these people are usually busy and being the filter can put a<br>
lot of stress in them (holidays, exams, problems at home... and a dozen<br>
of developers waiting for you to press a green button).<br>
<br>
This is why this option is preferable. Skilled humans can still test<br>
whatever comes and raise the blocker bugs, before or after the final<br>
release.<br>
<br>
In fact, what we probably should and will do is test more those apps<br>
that are most downloaded, for a simple logical reason: they are more<br>
used. Also, more automated testing and torture could be put on the most<br>
downloaded apps. But doing intensive and reliable testing on every<br>
package uploaded is not scalable, probably not even when automated since<br>
there are all kinds of apps, languages, dependencies...<br>
<br>
If a major bug could make it inside a final release of an app downloaded<br>
50 times and the chance for the bug to explode is 1/1000... tough luck.<br>
It happens all the time.<br>
<br>
<br>
2 weeks in the pipeline in exchange of free true testing and the trust<br>
of Nokia for potential promotion and collaboration sounds like a good<br>
deal to me. Testing the latest software 2 weeks before any regular use<br>
even sees the releases sounds also like fan and a good deal for the<br>
betatesters.<br>
<div><div></div><div class="h5"><br>
--<br>
Quim Gil<br>
open source advocate<br>
Maemo Software @ Nokia<br>
</div></div></blockquote></div><br>