> Its not the changes that are going into Emacs that are holding up the release.
> Its the requirement that all the items in the file FOR-RELEASE are completed
> first.
Perhaps. Still, in the past month or so there have been quite a few
comments about the success of the freeze (or lack thereof).
> That's Richard's choice, and clearly its his prerogative
Of course.
> but completion of the list might take a long time. If we fork now then every
> change that is considered to be a bug fix will have to be applied to both the
> head and the branch and it still won't speed up the release.
That it won't speed up the release is your opinion, and it's clear I
don't agree. There's no way to know who's right. What *is* clear is
that the current procedures do *not* induce speedy releases. As
discussed several times before, many projects, some with far fewer
people than this, do just fine with forking to prepare a release and
let people do new developments on the trunk. And in these projects,
people backports bugfixes to the release branch too.
And, as you say, completion of the list might take a long time; so
there's a kind of pressure on people to apply small new features to
the trunk. When I left Emacs development a year ago, the freeze was
already in place. I just don't want to count how many new features
have been installed since then.
All in all, I don't know what's the perfect answer. No one knows. But
I do feel than there's something wrong with a project the size and
importance of Emacs holding new features for three and a half years
(and counting). 21.1 was released on October, 21, 2001. So perhaps
it's time to think what's wrong with our release process, and "people
doesn't want to work on the issues important for the release" just
doesn't cut it: I don't think Emacs developers are very different from
other projects' people.
--
/L/e/k/t/u
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
