>>>> "Ilya" == Ilya N Golubev
Ilya> Having tag like 'current_stable_packages' or some other
Ilya> well- defined markup in cvs itself would make things much
I see no reason why it would. Under current policy, the right way for
Norbert to implement it is the way I implement it in 21.5: an
automatic "cvs -f tag -r this_release current_stable" when the tarball
is rolled out, ie, at pre-release. But CVS HEAD == most recent
release most of the time.
If Norbert wants to, I don't think anybody would object to a policy
change where he simply adds a current_stable tag at the time he moves
a package from pre-release to the main archive. Ie, implicitly a
short unofficial beta test period. But I would be opposed to turning
that into some kind of official beta test period, or having the
promotion to stable be delayed by depending on anything but Norbert's
judgment and convenience as it does now.
> The prerelease cycle is mostly intended to catch packaging
> bugs, not Lisp code bugs.
Ilya> But used for <Lisp code bugs> way too often. See package
Ilya> change logs for statistics.
If you think the package change logs have anything to say about this
issue, I have to wonder what logs you're looking at. I see no way to
determine from most change logs whether a bug was caught in the
prerelease stage, or after public release. Nor is there usually a way
to tell whether the bug was introduced in the changes leading up to
the current release, or whether it was present previously.
Now, if you track Norbert's announcements to see which ones put a new
version of a package into pre-release where the previous one was
already in pre-release, you'd have some data---but still not enough to
distinguish at which stage the bugs were injected.
Ilya> Besides, see no clear distinction between <packaging> and
Ilya> <Lisp code> bugs.
It's a packaging bug if the code does not install or load correctly.
If an error occurs after loading, it's a bug in Lisp code.
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.