Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March

[George Shapovalov]

Sunday, 2. March 2008, Steve Dibb Ви написали:
> Christian Faulhammer wrote:
> >  What we propose is proper testing and keywording by anyone
> > around...not just team members.
>
> I agree... our main problem is manpower -- people actually working on
> the stable bugs.  I've tried to do it myself a few times, but each time
> it just burns me out to the point where I don't want to (and won't) work
> on anything Gentoo-related for a time.
So, may be we should expand the number of "stability classes"? (something akin 
to my origina proposal, parst of which has been implemented, but looks like 
there is yet another usefull issue or two that did not make it yet :) (bug 
#1523, though probably not worth studying a this point as it mostly contains 
old stuff by now)).

Right now with packages being only "in testing" and "stable" we basically 
cover the audiences with stances "original dev says it works - it's fine for 
me" and "I want it rigorously tested". There should be plenty of people, who 
would be happy with an intermediate level of control. May be we should add an 
intermediate category with a somewhat automated workflow? So that the 
evolution of packages in the tree would follow such pattern (plus, of course, 
there are overlays for even less stable stuff):

1. as the package gets released it goes into the "testing", as it does now

2. After say 2-4 wekks (take your pick) without issues and possibly going 
trhough some compile-farm (automatically scheduled at the end of this period 
if no open bugs (normal or more severe) are detected) the package is marked 
as belonging to the "tested" category. This is where many users would set 
their running stability level and, in a way, participate in testing things 
for the next level.

If, any time after entering the "tested" state, package gets a bug assigned 
against it (again, normal or more severe) we start a countdown of, perhaps a 
few days, to let developers take care of the bug and if it does not get 
resolved within this time frame the package goes back to "testing". The 
decision to mask it or pull it off the tree completely remains with the 
respective devs, as it is now.
Some packages can be marked as "critical" to make them go back to "testing" 
immediately upon getting an open bug, should such effect be desired (might be 
usefull for some security-sensitive system packages, or may be not, due to 
possible breakage this may introduce. Still we are having such downgrade 
situations already from time to time).

3. "completely stable" profile, to which packages only go when explicitly 
requested and processed by stabilization team, as they are now. We should 
probably impose the requirement, that stabilization can only be requested for 
packages in the "tested" category.

The good thing about this approach is that it only requires an initial 
investment of organizing and automating things but does not add any regular 
work to the devs. In fact, if the "tested" category becomes popular enough, 
it can cut the work for stable testers, may be even by something like a 
factor of 10 eventually (due to less requests for explicit stabilizaion being 
issued)..

George
-- 
gentoo-dev@l.g.o mailing list