Re: High time to think about releasing 22.0

Eric> On Sat 11 Dec 2004 06:58, "Stephen J. Turnbull" Eric> <stephen(a)xemacs.org&gt; writes: 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. IMHO the reality of infrastructure today is that if it's not available under revision control for anonymous checkout, it's not in play. Your workspace is closed; nobody knows how much you care or what changes you're making to the code, until you get around to publishing a patch. So there's nothing special about "my" branch vs your workspace, except that it (a) announces that I care about eventually getting this stuff into XEmacs and (b) makes plain what I'm doing (or that I'm doing nothing, which is equally important) at a given point in time. I think you should do the same rather than worry that you're not getting a fair hearing. You'll notice that I'm the only non- contributor (in the sense that although I've done work, I'm not planning to try to push it into an XEmacs release soon) besides Mike running any version of the Xft patch, and it's getting on three years old now. But I already have one beta tester that I know of; I doubt it will be very long before there are others. The CVS branch did that, not my code (which is mostly yours and your predecessors', anyway). 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. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.