Re: What holds the release (was: mouse-1-click-follows-link)

[Juanma Barranquero <lekktu@gmail.com>]

On 6/14/05, Eli Zaretskii <eliz@gnu.org> wrote:

> I don't think the procedures are the main culprit, or even an
> important one.

I didn't say "the procedures preclude speedy releases", only that they
"don't induce" them.

> What holds the release is the enormous amount of
> mundane work to be done before we consider ourselves ready for the
> next release

This is part of the procedures I'm talking about. Or, call it quality
standards, if you prefer. It's obvious Emacs releases are of very high
quality. I, for one, would much prefer yearly releases of medium-high
quality than fourth-year releases of insuperable quality. I think
frequent releases (I'm not talking weekly or even monthly, but
certainly yearly doesn't seem outrageous) help increasing both the
user and developer base of a free project. (This is a subjective
perception, of course; YMMV.)

> and the relatively small number of people who get
> themselves busy working on those mundane issues.

Why so few developers involve themselves in "mundane" issues? Perhaps
they don't feel the issues are *that* important, or maybe they don't
feel qualified to do the work (I know that happens to me with a lot of
bugs, and certainly I don't feel comfortable writing English
documentation). But, whatever the reason, it is a *fact* that there's
so many people who will do the footwork, no more and no less. Three
years of freeze didn't increase the number significantly. Complaining
will not change things (I'm not speaking of you personally, of
course.)

> It's not useful to blindly copy procedures from other projects, IMHO.

I know. In fact, I think you said the same thing last time I brought
the issue ;-)

> Most of them don't get anywhere near Emacs in complexity and diversity
> of the features, nor are their different subsystems so loosely coupled
> as they are in Emacs, and so demanding many different talents and
> expertise in many almost unrelated fields.

Most of them do not. Some others do: Linux (kernel), GNU/Linux,
FreeBSD, Gnome, GCC... these are complex beasts and still they do
appear regularly.

> There are other important factors not to be forgotten: for example, the state of the
> documentation of most other projects is abysmal compared to Emacs,
> largely due to Richard's insistence on having the manuals updated and
> proofread several times before Emacs is declared as release-ready
> (which, of course, holds off releases, sometimes for a very long
> time).  Etc., etc.

I know that; Emacs documentation is one of its stronger points, and I
like it a lot. Still, many projects make do with suboptimal
documentation. It's nice having good docs, but good docs aren't any
good if they, and the features they document, stay on the CVS for
years and years.

I suppose what I'm saying is: yeah, I know what our rules are, and our
quality expectations. It'd be very nice to have a hundred people ready
to smash the release into being, by implementing these requirements
and in short notice. It's Just Not So. And so, we've taken three and a
half years in coming to a point where the release is not only not much
stable than a year or two before (I'm not saying "not more", just "not
much"), but the funny thing is: we *don't* know when we'll be able to
do a release. We can't plan. We can't have a tentative schedule. We're
somehow hoping that we all will feel guilty or something and stop
developing new features and go hacking at etc/FOR-RELEASE items. I
don't think that's likely. I'm not diminishing anyone's work by saying
that: I know of the people who's steadily improving documentation,
etc. But results speak by themselves. I don't know what the magic
bullet is, but arguments and feelings aside, I don't think anyone can
negate the truth that we aren't doing new releases. That's a fact. So,
we can consider what we do, and what we ask for a release, and decide
whether we are doing (and expecting) the Right Thing or not.

Last time we discusses that I brought the example of Subversion (and
was said it was a much smaller project :). I know. But they do
something which I find quite interesting: they plan a release, and
they try hard to stick to the date, even if they *know* it won't be
perfect. They're not afraid of getting 1.2.0 out even if they know
about non-critical bugs; 1.2.1 will follow in a few weeks. I think
this generates good karma.

-- 
                    /L/e/k/t/u