Re: branching in packages?

This is the trouble: requesting additional information that is not only ill- defined for automatic processing, but not stored in cvs at all. Unlike xemacs core, where all that one needs to obtain current versions is cvs repository - perhaps even its local copy, in which case no network transfers are done at all - except automatic background synchronization of the copy. Even if have saved, along with xemacs cvs repository copy, (current) listing of master package download directory, - there is no well- defined procedure to match its items against tags in cvs. At least not one that is obviously automated. For each package one has to do the following. . Determine latest package file name from listing. . Take package name and version from it. . Convert it to version tag that *should* be in cvs. Perhaps it done the same way for all packages, perhaps not. If the tag is there, all right. What if it is not? . `cvs update' the package with that tag. Hope that this is enough to show that obtaining current stable package sources snapshot is non- trivial. Having tag like 'current_stable_packages' or some other well- defined markup in cvs itself would make things much simpler. But used for <Lisp code bugs> way too often. See package change logs for statistics. This is why posted initial message on this subject in the first place. Followed up discussion of Lisp code bugs in one prerelease package: `comint' + `shell' in `xemacs-base'. Besides, see no clear distinction between <packaging> and <Lisp code> bugs. If there are some local Lisp code changes in xemacs package cvs, and new author / upstream package version is merged, is this <packaging> operation? Whatever it is, merging can easily generate definite <Lisp code> bugs. Would be happy to see this practice commonplace. But currently it is as described above.