XEmacs 21.2 CVS is shippable now, modulo a few little things like NEWS files and other documentation. At this point it's only two weeks to your suggested deadline for major feature contributions. I suggest you not bother and simply ship what we have on Feb. 1. Put together a NEWS file, turn off widgets by default, leave pdump off by default (on Unix), and put out the release. But Stephen, you're doing most of the work, so you get to call the shots. I'm torn on the question of the new numbering. We'd like to have 22.0 have all the new features, but it won't. So call it 21.4.0. When gtk-xemacs and Mule on Windows is integrated, we release 22.0. SJT> When should we open the 21.5 development branch? (My proposal is to SJT> rename it to 22.1 when we're sure that the current release will be SJT> 22.0.) I have that tentatively scheduled for next week. Is that too SJT> soon? The worst thing would be for new development to grind to a halt while we wait. SJT> Do we know how to move the head of trunk to that branch? When should SJT> we do that? I suggest we cut the branch for 21.4 on Feb. 1. I volunteer to do the CVS hacking to put 21.5 on the trunk, although if there are eager CVS-savvy volunteers out there, they can contact me and get the job themselves.

Andy> At 20:24 14/01/01 +0900, Martin Buchholz wrote: Andy> I'd really like us to revisit this since we have never Andy> actually made a decision. I believe that I have nuked pretty Andy> much all the widget bugs in the X version as well as the Andy> windows version - so I would like to know what in particular Andy> means that we have to switch it off by default? I'm sorry, maybe this is my bad. Perhaps I should have clarified the policy earlier, but I've been hoping for discussion from the Board. Martin has expressed his opinion several times. The only support for it is his unquestioned general expertise, to which I have given due consideration. Against that, he has pointed to no specific bugs or incompletenesses. In favor of continuing present policy (detailed below), I count o the unanimous silence of the rest of the Board as tacit assent o the expert opinions of the implementors of each feature as clear indicators in favor, and o the fact that the very risky features are on CVS branches and not planned for immediate merge to the release line as reason for delaying decision on those until we've got something to look at. As of right now 0. The proposal, which was not disapproved by the Review Board and I am therefore implementing, was to take big risks for the potential big wins of "GTK" and "Mule on NT," moderate risks for the very nice features "pdump" and "widgets," and minor risks for the remaining recently finished or nearly done stuff. This remains Release Manager policy. It is subject to Board override or me changing my mind. I've seen no hard evidence to make me change my mind, and no sign whatsoever of a Board minority against it, let alone enough of a majority to be called an "override." Specifically: 1. The widgets are _in_ the release and _on_ by default on all platforms until I see either (a) bug reports that indicates that they shouldn't be (Martin's whinging is not a bug report) or (b) a Board override. Tester releases will reflect this. 2. A similar policy applies to the portable dumper. Martin, please make configure{.in,} reflect the above policy. (If you haven't time, I'll do the best I can, but I don't have a lot of experience hacking configure.) As for the big risky features: 3. Mule on NT is _in_ the release, but the merge work will be done on a branch. If the merge is going to be as late as Ben currently believes, it will _not_ be merged into the release branch. Then it becomes Martin's problem, or my successor's if we are so lucky as to find one. The next decision point is when Ben asks for a merge or Feb 1, whichever comes first. 4. A similar policy and decision date applies to GTK. -- 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."

mb> XEmacs 21.2 CVS is shippable now, modulo a few little things mb> like NEWS files and other documentation. No, it's not. It will be Feb 1 at the earliest before I will be ready to think about shipping this. I don't really have a good idea what it is I have committed to shipping yet, let alone documents written about it. mb> I suggest you not bother and simply ship what we have on mb> Feb. 1. Now _this_ is a truly crackpot idea! :-) You realize that all open source development will come to a stop, perhaps for years, as the entire community has a collective heart attack when a major app, an Emacs, yet, is released a month ahead of schedule? mb> But Stephen, you're doing most of the work, so you get to call mb> the shots. That is probably what will happen, since Bill Perry is not talking and Ben is projecting delivery much too late. However, I've been believing in magic and miracles since the days of the Mamas and the Papas and Fleetwood Mac; this is not the time to stop. Ben could deliver a miracle. Bill has a working prototype (based on 21.1) and code that builds from 21.2. Just a little magic... I'll keep believing until Feb 1. mb> The worst thing would be for new development to grind to a mb> halt while we wait. As you should know by now, I disagree wholeheartedly. New development can always be restarted if it's stopped artificially (eg, by feature freeze). Except for Mule/NT, all of the projects that might be hard to restart are done, except for testing. Filling buffers is easy. Flushing them without corrupting the contents is the hard part. Vin evidently agrees with me: vin> Yes, next week is too soon. Everyone should be focused on vin> the current version, not the _next_ version. The XEmacs vin> project is now in a period of stability, and contributors vin> should focus on supporting the release effort. Unfortunately: vin> Opening a development branch will distract the contributors vin> when we should all be aiming towards the fast-approaching vin> release. Realistically, they're already distracted. The only sensible thing to do is damage control. My feeling is open the new devel branch now, so there's a place I can arbitrarily divert patches to without getting lynched. SJT> Do we know how to move the head of trunk to that branch? SJT> When should we do that? martin> I suggest we cut the branch for 21.4 on Feb. 1. March 1. That's the scheduled date, and I see no reason to advance it. I would like to have a testing period with widgets and pdump in, even if we decide to default them off. -- 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."

mb> Of course you misunderstood me. I didn't mean shipping on mb> Feb. 1, I mean seeing what we have on Feb. 1 and shpping THAT. OK. If you add a bit of wishing for miracles, that's exactly what I've been planning to do. Sorry if I haven't been clear. mb> Later. In practice we would intend to ship March 1, but in mb> fact ship April 1 -- business as usual. Uh-uh. No flexibility. We decided not to go there, remember? Nope. No way, no how. If we aren't looking like we're going to be able to ship on March 1, I will fall on my sword in whatever seems the most honorable way. I cannot promise to continue actively managing much past April 1. If Vin looks at what we've got on March 1 and says he "can't imagine it being acceptable as stable before June and without major rewrites," I think we will probably have to abort the release. Yes, I am aware that probably means that neither GTK nor Mule/NT will get in if we take a realistic look at their state on decision day. We'll see what things look like on Feb. 1. mb> If you really want me to do the CVS work, I'll start on it mb> now, but I prefer "wait and see" wrt a new branch. I think everybody would be much happier if we all know ahead of time what the technical details and risks are. I know I would be. I see a lot of potential for this to completely break CVS for a week; I don't see any expendable weeks between now and April 15. mb> We shouldn't have repeated CVS churn, so whenever we create a mb> new branch for the new stable version, we should also move mb> development to the trunk. My desiderata for the CVS move are (1) The current devel branch stays a tagged branch and does not become trunk until after the stable branch is created. (2) The "gamma" release will involve a branch off the current devel branch and new tags. The only code change relative to the beta current at that time will be version information. (3) Minimal risk[1] to Vin's ability to work on 21.1 "same as it ever was" until he accepts the "gamma" code as stable. We'll need to ask Vin, but I imagine he would consider it acceptable if he had to use a tag, as long as it doesn't impact his ability to access CVS history and status etc. Ie, the new devel branch takes _all_ the impact of any "CVS churn." I think that is "obviously" the right thing. Even if it means waiting until May to move the devel branch to the trunk. Even if it means extra CVS churn. Comments? Footnotes: [1] Since 21.1 is currently the trunk, "no risk" is obviously not possible. -- 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."

Stephen J. Turnbull wrote: <FWIW>Count me in too.</FWIW> -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 53 14 59 47 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

-- "David A. Cobb" <superbiskit(a)home.com&gt; spake thusly: In light of this wisdom, perhaps the decision by several major open source projects to make odd versions development and even ones releases was a poor one. :-)

David> Hey, 's OK with me either way. Maybe the leading lights in David> all these Open projects consciously decided to reverse the David> "commercial" world. Let's see: Windows 3.0 (Zero being David> even), IBM anything .0, DEC (remember them) anything.0. It David> wasn't "beta," This connotation is quite justified in the case of the next XEmacs release. That's _exactly_ why I wanted the .0 tag, so the risk-averse would be warned. As for the even/odd thing, we don't have a policy at present. Martin advocated "like Linux and Perl", and the motion carried 1-0. That's democracy in an open source project. :-) And I will shortly be announcing that we're going to release 21.4, not 22.0, anyway. :-) -- 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."

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: Just curious, but if what we have currently is... 21.1.x - stable branch 21.2.x - development branch Shouldn't the next major release be... 22.1.x - stable branch 22.2.x - development branch Or even... 21.3.x - stable branch 21.4.x - development branch I just think that it will cause confusion if we change the stable minor releases from odd to even and the development minor releases from even to odd. -- |---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

S> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: S> Just curious, but if what we have currently is... S> 21.1.x - stable branch S> 21.2.x - development branch S> Shouldn't the next major release be... S> 22.1.x - stable branch S> 22.2.x - development branch Actually, assuming it's worth an increase in the major number, 22.0.x - stable branch 22.1.x - unstable branch S> Or even... S> 21.3.x - stable branch S> 21.4.x - development branch S> I just think that it will cause confusion if we change the stable S> minor releases from odd to even and the development minor releases S> from even to odd. If projects have an even/odd numbering for stable/unstable, then folks expect the `odd' numbers to be unstable. Like the Linux kernel. It's our current convention that is confusing. I think switching to the other will cause even more confusion short term, but perhaps be better long term. I don't feel strongly about this.