On 11/10/06, Paul Mitchum <[EMAIL PROTECTED]> wrote: > > On Nov 10, 2006, at 4:49 PM, [EMAIL PROTECTED] > wrote: > > > Date: Fri, 10 Nov 2006 09:27:08 -0800 > > From: "Lars Rosengreen" <[EMAIL PROTECTED]> > > > > On 11/10/06, Paul Mitchum <[EMAIL PROTECTED]> wrote: > >> > >> On Nov 10, 2006, at 1:27 AM, "Lars Rosengreen" > >> <[EMAIL PROTECTED]> wrote: > >> > >>> How about making the unstable tree enabled by default on new > >>> installs? > >> > >> Or, perhaps *move packages into the stable tree on occassion.* > > > > A lot of maintainers wait for some positive feedback from users before > > moving a package into stable. If you use a package and think it is > > ready > > for stable, please let the maintainer know. > > Well, see, this is exactly the can of worms I was hoping to open. :-) > > Why should users get to determine which packages are 'stable' and > which aren't? If the threshold between stable and unstable is that > users are OK with it, then it seems that packages without outstanding > bug reports could be automatically moved to stable after, say, six > months or something. That would make the process both more > transparent and predictable, and also less of a headache to > maintainers. Even if it weren't set up to be automatic, there might > be a twice-yearly Race To The Stable Day, where maintainers could > race to make their packages stable by clearing bugs from the tracker. >
The main reason for needing user feedback is because sometimes people maintain packages that they don't use themselves. Lack of bug reports could mean that a package hasn't been installed by anybody, and in such a case it could be broken without anybody's knowledge. I'd put the onus for a call to stabilze the package on the maintainer: they should send a message to the lists asking for somebody (else) to install the package and try it out. (As a side note, using the bug tracker to report package bugs isn't usually the best option, because there's nothing that sends a message to the package maintainer automatically so that they even know a bug report has been filed. Typically results are better when they're contacted directly) > But whether that's the solution or not: I think fink would really do > well to adopt a very clear policy on when and how packages should > move to stable. More packages would end up as stable if a clear > policy were in place. > > I say this having searched for such a policy and being unable to find > one. If it already exists, then I'd be glad to see it. > > There isn't one, apart from the necessary conditions that I mentioned earlier in this thread--it has been left up to the individual maintainers to decide when/if their packages are ready. -- Alexander K. Hansen Fink Documenter (still) ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
