Re: Reordering etc/NEWS

[David Kastrup]

address@hidden (Kim F. Storm) writes:

> Richard Stallman <address@hidden> writes:
>
>>     But we are not your enemies, and this is not a conspiracy to
>>     badger you.  It just happened that quite a few of us disagree
>>     with your ideas
>>
>> And some of them have been badgering me to do things their way.  I
>> don't want to participate in discussions with that feel to them.
>
> I don't know if you feel that _I_ have been badgering you, but that
> has never been my intention -- my only concern has been for the best
> of the project.
>
> You obviously have very specific ideas and principles on how to
> "make progress towards" a release -- but it is also a fact (IMO)
> that those ideas are not efficient in terms of actually "making" a
> release.

The suitability depends on what one wants to release.  For GPLv3, it
is quite appropriate to take all the time it takes for the finishing
touches.

But Emacs is not a work to be _finished_, it is a work to be
continued.  And the continuation has been blocked for years by the
release.  At the current point of time we have reached the state where
nobody knows what the HEAD and release branches are supposed to be
for, respectively.

The situation has been bad for development for years.  Right now it is
catastrophic for _any_ work since there is no place in CVS which is
designated for work of any particular kind.

Creating additional branches unnecessarily to get any work done causes
additional merge burdens later.  And there is no sense in having
proliferating branches because the project maintainer refuses to get
"badgered" into telling people what the policy concerning the branches
is supposed to be.  Creating desperation branches is no solution,
since the merge decision still depends on an active statement of
policy.

I don't get it.  Most of the developers on this list have invested
large amounts of time and energy into making Emacs as great as it is.
Considering them enemies does not make sense, and it makes even less
sense to stop _every_ developer in his track as a sort of collective
punitive measure.

We need to know what kind of work can commence on HEAD and the release
branch, because some of that work requires a concerted effort (like
the multitty merge) of several people.

-- 
David Kastrup