Re: branching in packages?

Ilya> Having tag like 'current_stable_packages' or some other Ilya> well- defined markup in cvs itself would make things much Ilya> simpler. 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. 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.