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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
