High time to think about releasing 22.0
Stephen J. Turnbull
stephen at xemacs.org
Mon Dec 13 00:59:47 EST 2004
>>>>> "Eric" == Eric Knauel <knauel at informatik.uni-tuebingen.de> writes:
Eric> On Sat 11 Dec 2004 06:58, "Stephen J. Turnbull"
Eric> <stephen at xemacs.org> 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
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',
Eric> My plan was to submit a patch against your Xft-branch pretty
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.
More information about the XEmacs-Beta