Proventester request - xulrunner, firefox, gjs bugfix update

[James Laska]

On Fri, 2011-02-11 at 21:35 +0000, Jóhann B. Guðmundsson wrote:
> On Fri, 2011-02-11 at 15:36 -0500, James Laska wrote:
> > Behold, the branch point is upon us!  Once branched, it's no longer a
> > free for all.  Time to stabilize the release according to the
> > established release criteria [1].  This is especially important while
> > attempting to build an Alpha. 
> 
> Then perhaps the branch point should be move til beta or we need to
> rethink the proventesters process.. 

I'm not sure what rethinking is needed, but I certainly welcome
identification of real problems and proposals to address them.

> I looked at the idea loosely when it got proposed and what you need to
> do is taking the number of signed up proventesters then figure out how
> many of those proventesters are running rawhide as opposed to F14
> updates-testing and F13 updates-testing but let's just say that each
> proventesters is running all three then, take the amounts of update and
> the average time it takes each proventester to install and perform
> minimum testing on the component being updated etc. etc. etc. and the
> rate we are pulling in proventester yata yata  ( We probably have few
> math experts that can lay down the math for this completely and they can
> probably also deliver the math of the required amount of proventesters
> limited to just the component on the media we hand out to people ) and
> I'm no rocket scientist but I soon came to the conclusion that we cant
> cover all the component with the rate we are pulling in proventesters
> and new components being introduced thus this solution does not scale on
> distribution level and rather acts as an obstacle to the development
> model we have in place and our end user then a benefit.  

This is working as designed.  We are stabilizing a release, we should no
longer be developing features, but fixing bugs introduced by those
features.  Throughout all of F-14, and since it's release, packages have
been landing in rawhide and receiving some initial sanity from testers
+maintainers.  The flood gates were open and anyone can push anything
into rawhide.  Now it's time to turn this into a release we can all be
happy with.  We've demonstrated for many releases that continuing to let
anyone push anything into the release at any time ... results in
consistent schedule slips.

If someone pushes out an update, doesn't propose any addressed bugs for
the blocker review, and no one installs or applies karma, I'm 110% okay
with that no going into F15.

We scale by allowing karma from proventesters (and anyone else) to allow
a proposed update into the release.  We have slightly higher karma
requirements for critical path packages, and we have exception handling
by way of the blocker release criteria+process.

You point out an area that does need improvement, but I suspect is a
level above "proventesters".  The number and frequency of updates.  That
topic is for another (and previous) threads.  With regards to
proventesters, you are right, I'd like to see us improve visibility into
what release coverage we have with proventesters.  We just don't have
that data afaik.  I'd also love to see greater visibility into who our
most active proventesters are.  I believe some of this insight will be
possible with the next major release of bodhi.  

If anyone out there knows some python/perl/php/$script_lang, there is
plenty of opportunity to start familiarizing yourself with the bodhi
XMLRPC interface, and experimenting with the data.

> And all of the above is beside the point that I am unable to test any
> Gnome desktop app due to mutter constantly causing segfault in my
> display driver at this point and I suspect other reporters are in same
> or similar shoes. 

Same here :)

Thanks,
James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20110212/03a23f3e/attachment.bin