Nightly CVS tarballs

SY> We don't do this do we? I think that this would be trivial to SY> set up (via a shell script and cron). Would anyone mind if I SY> did it? You can if you want, but I think it's a waste of space. Many of them won't even build, so people will have to backtrack. Often as much as a week or more on oddball platforms that don't get frequent builds. That means you really need to make patchkits too which is somewhat hairier (although Martin automated that with makepatch and I'm getting pretty good results too.) CVS is a much better way of doing this. I believe the real problem is too infrequent certification of minimal quality by beta release. It's not that admin's are unable to use CVS. This won't do anything except speed up the mess. But let's hear from the testers on this. SY> I was thinking: SY> - a 21.4 nightly tarball Don't. 21.4 doesn't change until just before I do a formal release or prerelease. Either way it's done with a fair amount of care, and automating it wouldn't do _me_ any good. I've got all the automation I can use already. All you could do with an automated process that doesn't track my schedule is guarantee unnecessary breakage. - a 21.5 nightly tarball You will almost surely regularly get checkouts in the middle of a commit; XEmacs development is 24 hours a day. But commits aren't atomic. Is it worth it? - a packages nightly tarball Same as 21.5. - perhaps individual package nightly tarballs This makes sense; people typically don't build their own packages, but download them with pui. This would free you from explicitly making "pre-releases," all you7d have to do is announce them. I think that's a good idea. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."