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 -- [email protected] mailing list
