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."

Peter> Stephen J. Turnbull writes: Peter> i was thinking what you said stephen but thought i would Peter> wait to see what the core dev team said Please don't wait on us. While the people who do the work for practical reasons have final say, that doesn't mean we always know better than anyone else. And for something like this, we're the last ones to ask. We may sometimes seem to think it's "our XEmacs," or even "my XEmacs," but it's not. Some of the work may be ours, but _XEmacs is yours_. I think I can speak for the whole core dev team on that. -- 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."

SY> My motivation for this came about because I know of at least SY> one person whose firewall prevents them from using CVS. So in The firewall also prevents use of ssh? It would certainly be possible to make an anonymous retrieval only alias in Martin's auth files. We'd have to think about the security implications of that, but if the person would ask to formally recognized[1] as an XEmacs developer, or you're willing to personally vouch for them, it's probably doable. If they don't care that much, why should we care enough to go to this kind of trouble? It does have implications for our workload, over and above the setup of the cron job and the disk space. SY> that scenario whether or not the package will build is SY> probably not so important. Ask the person. SJT> - a 21.5 nightly tarball SJT> You will almost surely regularly get checkouts in the middle of a SJT> commit; XEmacs development is 24 hours a day. But commits aren't SJT> atomic. Is it worth it? SY> Development isn't that fast and furious is it? You're talking about doing this every day; the odds of a clean update on any given day are very good; the odds taken over a week are much worse. The odds over a month are bad. Anyway, when it is, it is. Right now is a lull; summers always are. Also, once I get out from under the start-of-term, I hope to do some recruiting.... SY> Granted there's a chance of getting a checkout in the middle SY> of someone else's commit, but the same can be said for SY> developers who use CVS anyway. CVS users can recheckout immediately and probably get a clean update. SJT> - perhaps individual package nightly tarballs SJT> This makes sense; people typically don't build their own SJT> packages, but download them with pui. This would free you SJT> from explicitly making "pre-releases," all you7d have to do SJT> is announce them. I think that's a good idea. SY> I get the impression you're thinking about this as another way SY> for users to get XEmacs or packages. Yes. Even if not your intention, it is that. That scares me. SY> That's not what I was thinking. I know; you don't field those bug reports. I do. ;-) Cf the guy who's been reporting 21.2.46 bugs. SY> It's more a way for developers who don't have SY> access to CVS to get hold of bleeding edge code so they can SY> hack to their hearts' content. :-) The fact is that the bleeding edge code _isn't on the trunk anymore_. It's on branches. So your theoretical developer without CVS access is S.O.L. anyway. 21.5-latest-beta is going to be pretty close to up-to-date, and it's very likely to build. Footnotes: [1] You know, like any of the committers. -- 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."

Jeff> Well, I would like to see the nightly cvs tarballs and Jeff> here's why. OK, that's two in favor. Jeff> Being able to download a tarred up cvs snapshot would, in Jeff> most cases, save me a lot of trouble. Well, if Steve Y wants to go ahead and take responsibility for it, I guess I'll withdraw my opposition for 21.5 and the packages. 21.4 is still a no-no for the reasons given. Two suggestions: 1. Provide a daily cvs diff in case the current day is broken. 2. Provide a diff against r21-5-latest-beta. A bit redundant, but helps to address the main problems I foresee (the code itself in CVS is often broken, and CVS concurrency issues). They should be small enough that people could just automatically suck them down too. Jeff> the problem i get doing this is: Jeff> *) shell scripts load execute permissions, i.e. configure. If it's only configure that's a problem, autoconf should fix it. But there are other scripts, and they're static. Jeff> *) while the .c files will generally compile, my non-mule Jeff> xemacs chokes on .el files with the dos cr/lf. So too, does Jeff> make on the similarly afflicted makefiles cvs update accepts the -kb "treat it as binary" flag. This may or may not help depending on how the files are stored in the repository. Jeff> *) the majority of the files that have some kind of case Jeff> dependent filename generally lose the case. That's weird. None of the above is intended to say "we shouldn't have nightly tarballs," just offered in hope of easing the pain in the meantime. -- 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."

SY> Do you mean, a diff against the previous day? Easily doable, SY> but is it necessary? Yes, and no. Just convenient for someone who doesn't have a nearly bleeding edge copy. Either new to the bleeding edge or haven't hacked it since the last beta. Second, it's useful documentation to see where recent activity is. I use CVS that way all the time, it's more accurate than anybody's ChangeLogs except Ben's. SY> I don't know about other developers, but if I didn't have SY> access to CVS for whatever reason I'd be keeping a working SY> backup. Working, yes, bleeding edge, no. Not everybody has the luxury of waiting 'til tomorrow; for many developers, "tomorrow" will be _Monday_. SY> People who hack from a nightly CVS tarball have to realise SY> that the code they have could be up to 24 hours out of date SY> and need to make allowances for that. Such as, if the current SY> day is broken, wait until the next day's tarball is SY> released. (Of course, they are quite welcome to fix the SY> breakage.) SY> Is that too harsh? No. But if the point is to make it convenient for people who don't have normal (== CVS) access to hack bleeding edge XEmacsen, why not take out some nearly free insurance? It costs us almost nothing to make the two diffs I propose. Two or four lines of code, 100kB (if Ben or Martin is in top form) of disk space. If that means that once in the next year somebody who otherwise would not be able to work on XEmacs _now_ can work on XEmacs _now_, I think it's worth it. But you're doing the work. :-) It also means that if somebody reports a compile bug against "today", we can reply "did you try yesterday?" if the cause isn't obvious instead of digging around in the code for a bug that very well may not be there. -- 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."

|--==> "SJT" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp&gt; writes: SY> People who hack from a nightly CVS tarball have to realise SY> that the code they have could be up to 24 hours out of date SY> and need to make allowances for that. Such as, if the current SY> day is broken, wait until the next day's tarball is SY> released. (Of course, they are quite welcome to fix the SY> breakage.) SY> Is that too harsh? SJT> No. But if the point is to make it convenient for people who don't SJT> have normal (== CVS) access to hack bleeding edge XEmacsen, why not SJT> take out some nearly free insurance? OK, I have a working model that I'm testing locally. If all goes well, I'll put it "online" after the weekend. ,----[ main comments from script ] | Commentary: | | This script creates nightly cvs snapshot tarballs of XEmacs 21.5 and | of the XEmacs packages. | | For 21.5 it creates a diff between the latest released beta and | current CVS. It also creates a diff between yesterday's CVS and | today's. Providing that the latter diff is greater than zero bytes | long, a tarball is created and it together with the 2 diffs are | moved to the FTP directory. | | For packages: Check to see if anything has changed since yesterday | and if so, create tarballs and move them to the FTP directory. We | create a "uber" tarball of all packages; a tarball of all standard | packages (if the change was in a standard package); a tarball of all | mule packages (if the change was in a mule package); and a tarball | of any individual package that has changed. | | If any snapshots are created an announcement is sent to xemacs-beta | listing the newly created snapshots. If anything goes wrong an | email is sent to $ADMIN (youngs(a)xemacs.org) so they can fix it. `---- And for those who are interested, here's the script. -- |---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|