High time to think about releasing 22.0
knauel at informatik.uni-tuebingen.de
Tue Dec 14 14:44:44 EST 2004
On Mon 13 Dec 2004 06:59, "Stephen J. Turnbull" <stephen at xemacs.org> writes:
>>>>>> "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
> 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.
Ok, I probably misunderstood. I just received the impression, that my
patches to the Xft branch would not be welcome for some reason.
> 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.
This is a fair offer. I absolutly agree with you that developing,
fixing and maintaining the patch in workspace which is not publically
available makes not much sense. So, what do I have to do to get commit
access to the branch?
> 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
> 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 agree. This approach for working towards a fixed and finished patch
which in shape for committing it to the mainline makes sense to
me. The way I'm working right now is rather tedious.
> 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.
Sure, if it makes things easier! However, I'm not sure if I
understood that completely: which merges are you referring to?
"Excuse me --- Di Du Du Duuuuh Di Dii --- Huh Weeeheeee" (Albert King)
More information about the XEmacs-Beta