On Wed, Feb 09, 2005 at 09:11:16AM +0200, Yaron Tausky wrote: > Therefor, I would like to suggest that each ebuild would include a "Testing > Period Expiration Date" -- a variable containing a date after which the > ebuild would automatically considered stable, unless the maintainer chose > otherwise. This will take a lot of work off the hands of package > maintainers -- instead of having to look after every ebuild and mark it > stable, they would only have to take care of malfunctioning ones, yet it > would still allow a proper testing period before release. No, for a great many reasons - as previously discussed on this list.
My own primary reason is that for a number of packages I maintain (because I use specific features/components of them), is I don't use enough of the package to consider even my daily usage a fair gauge of stability. This is even more of a problem with applications that have prolific featuritis and no complete test suite for those features. I just don't trust the application enough to mark it stable yet. > Recently I encountered far too many packages for which the latest > stable ebuild was AGES old. For the vast majority of these cases the > unstable ebuilds were perfectly functioning, if not better than the > stable ones due to upstream bug fixes. Until now I used to report > these cases as bugs, but I believe it's not very efficient. I believe I speak for most developers when I say we would like more stability reports for packages (once they have passed their 30 day testing window). So keep filing them! -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpAH7vRfnft1.pgp
Description: PGP signature
