Re: High time to think about releasing 22.0

>>>>> "Eric" == Eric Knauel <knauel(a)informatik.uni-tuebingen.de&gt; writes: Eric> On Sat 11 Dec 2004 06:58, "Stephen J. Turnbull" Eric> <stephen(a)xemacs.org&gt; writes: >> IMO Eric's most recent patch is even less ready than my branch. Eric> I find this statement rather annoying. Why? It's simply the truth that that is my opinion. Given that I have the power to seriously hinder any attempt to get your code committed to mainline, I rather think I have the responsibility to say that publically. Among other things, that gives you the option of lobbying the Board for a more lenient standard starting _now_, if you want to. I'll oppose it, of course, but I won't hold it against you. Eric> My plan was to pull together instead of starting some sort Eric> of competition. That's not competition; I have no intention of merging my sandbox to the mainline without substantial improvements. (Among other things, CVS's deficiencies make any attempt to merge both ways an exercise in frustration; a branch is really only useful as a public history of a workspace up to a once and for all merger back to mainline.) I don't care "whose patch" gets in, and frankly I'd rather have you guys do most of the work, and a lot sooner than I'm likely to do it.

Eric> My plan was to submit a patch against your Xft-branch pretty Eric> soon. Good. If it builds on at least two different machines, feel free to commit the patch to the sjt-xft branch while you're at it. It doesn't need my approval, just the patch to xemacs-patches, and a tag if there's a chance someone might want to run without your patch for any reason. This patch sounds more than big enough to need a "pre-commit" tag. Use something like "cvs tag sjt-xft-NNN" for the tag. No need for a post-commit tag, at least for now. "cvs update -j tag-thats-broke -j tag-that-works" means never having to say you're sorry. As long as the tag-that-works is fresh enough. :-)

Eric> I hope that my contribution to your branch is welcome (given Eric> that it is technically ok). Sure. But it's not a matter of technical quality, really. It's a matter of design taste. If it looks like your patches would make it difficult to do things the way I think they should be done, I'll ask you to make your own branch. But until it actually comes to that, we may as well avoid redundant synching across branches and to mainline. Asking you to make a separate branch doesn't mean my branch is on the fast track, either, except to the extent that other developers trust my judgment more than yours. But I don't have a problem with you doing the work your own way, I'm just going to oppose committing it to the mainline until certain fundamental issues are settled.

I do have a word of advice. Get one of the advanced revision control systems (to my mind that means arch or darcs) and do any merges in a local repository for the advanced system. Even if things work out that we can share the sjt-xft branch all the way to integration, it makes a lot of operations easier, and can be essential if whoever is handling "synch-to-mainline" flakes out for a month.