On Fri, 05 Jan 2007 17:23:51 -0700 Steve Dibb wrote: > Daevid Vincent wrote: > > But as I read this thread, it seems that in effect, I won't really > > be getting a more stable system, I'll just be getting an older, out > > of date one, as nobody is actively monitoring packages and then > > flagging them as stable. :( > > > The problem, like many other things, comes down simply to manpower. > > I should stress, again, that popular, common applications and > utilities are going to get marked stable on a regular basis. For the > most part, its only the small, fringe programs that get lost in the > cracks. > > And getting some tools in place to display how long packages have > been unstable is in the works. Still though, there is just so much > work to be done in the first place, not many developers go looking > for things to mark stable. It makes things a lot simpler if that > offload is placed on the users instead, because that way 1) we don't > focus manpower on stabilizing everything just because its been 30 > days and 2) we stabilize stuff that people are using anyway, and want > to get marked stable. > > Steve
I've been reading this thread as well as the earlier (July) threads (from gmane) and notice that everyone is discussing "30 days", "automatic", and "stabilization bugs". What if there were 2 time periods - a minimum and a maximum. For example: with a 30 day min, a package would have to be bug free for 30 days before a stabilization bug _could_ be acted upon. If there are no open bugs and no stabilization bug was submitted , then a maximum period (perhaps 60 days, perhaps 6 months) would cause an _automatic_ upgrade to stable. Having an acceptably large max period would take some of the load off of developer shoulders and would prevent the current situation of having really old ~ARCH packges (some of which currently seem to measure in the hundreds of days). Just my $.02 David -- gentoo-user@gentoo.org mailing list
