emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Syncing Gnus and Emacs repositories


From: David Kastrup
Subject: Re: Syncing Gnus and Emacs repositories
Date: Sat, 16 Jun 2007 14:09:54 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Date: Sat, 16 Jun 2007 00:12:56 +0200
>> Cc: address@hidden, address@hidden, Nick Roberts <address@hidden>,
>>      address@hidden, address@hidden, address@hidden
>> 
>> It just appears quite pointless to be driving with the handbrake on
>> after we passed the point of the release.
>
> I don't necessarily agree with Richard's decision, but can you
> explain why should it be a drag on the development?  If someone
> wants to make far-reaching changes, they could always switch to the
> Unicode branch and make them there, can't they?

And that is going to make merging unicode-2 into the trunk easier just
how?  And if we are considering new feature branches, should they be
based off unicode-2 in order to have the ability to prepare stuff
intended for 23.1?

> Also, please note that it was Ken'ichi who asked not to make changes
> on the trunk that would make it harder to merge the Unicode branch;
> if you want to be fair, why don't you lobby Ken'ichi as hard as you
> lobby Richard?

Why would I?  What is the plan for the trunk?  The two opinions
here are:

Richard) Let's keep the trunk close to 22.1

Ken'ichi) Let's keep the trunk close to unicode-2 so that we can move
          forward soon with merging, and don't have extra effort to
          move Emacs to 23.1.

The difference is that I see no useful "so that" for Richard's desire.
The direction of development should be forward, not backward.

Would Ken'ichi complain if we merged unicode-2 into the trunk
tomorrow?  I doubt it.  There is a _purpose_ to Ken'ichi's request,
and that purpose is to facilitate move development forward.

I fail to see a similar purpose to the request of Richard.

>> The current plan, however, seems to be "let's achieve as little as
>> possible over as long as possible".
>
> That's just being vicious, David.  There are ways to say what you
> want without assuming malicious intent such as this, which Richard
> clearly cannot have.

I don't see where I am stating malicious intent here.  It is quite
obvious that Richard does not consider a stop of development a bad
thing, or he would hardly argue for it.

I consider it a bad thing, actually a very, very, very bad thing: now
that Emacs has come a bit up on the radar of media and user attention,
the main message to be gleaned from the developer lists is that we
actively refrain from using that opportunity to have the glacial
development of Emacs pick off.  Worse, people are discouraged from
thinking about the next release: instead it is mandated that we stop
development for "a few months".  One of the points of branching
EMACS_22_BASE and making the 22.1 release was to be able to move
forward again after _years_ of stalling and freezing for "a few
months".

If I were of the opinion that Richard was being malicious, I would not
argue with him.  In his political work, he is thinking and working in
time frames of decades and lifetimes: that is the scale at which
shaping the flow of global thinking takes place.  Opportunities for
changing the twist and turns of humanity are rare to come by.

The flow of coding is that going on in spurts at night and on
weekends.  Opportunities for changing the twist and turns of program
code arise and fall by the wayside daily.

Pausing for several months for no discernible reason is _costly_ in
programming, in particular in a distributed project.  In politics,
that is the normal state of affairs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

[Prev in Thread] Current Thread [Next in Thread]