all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Óscar Fuentes" <ofv@wanadoo.es>
To: help-gnu-emacs@gnu.org
Subject: Re: Release date of Emacs 24.4?
Date: Mon, 10 Feb 2014 03:21:51 +0100	[thread overview]
Message-ID: <87lhxjbtc0.fsf@wanadoo.es> (raw)
In-Reply-To: e2368f8c-acf5-41f7-90ff-3b9a49b4c7e1@default

Drew Adams <drew.adams@oracle.com> writes:

>> AFAIK a release is planned to happen in a few weeks.
>
> Really?

Not sure. The maintainer's explicit goal is to speedup the release
cycle. Under this maintainer, past release's pretest phase was much
shorter than under RMS. I wouldn't be surprised if the release is made
two months after the end of the feature freeze.

> There hasn't even been a pretest announced and distributed,
> has there?  Where is the announcement asking people to test the
> pretest distribution?
>
> What about the pretest testing period?  Has that been reduced to
> at most a few weeks now?
>
> There are thousands of bugs reported now, including many newly
> introduced.  Do we really intend to ship a release only a month
> or two after closing the addition of new features?

That was not what I was suggesting. Emacs is on feature freeze for 6
weeks now (IIRC) and it seems to me that the maintainer wish to
stabilize (*) it enough to turn the pretest phase into a mostly
packaging test exercise.

I think this is a sensible approach. How much pretesters do we have,
compared against the number of users who use the development version of
Emacs on a production environment? Packaging and exotic platforms aside,
the pretest phase discovers a tiny amount of bugs.

> Not adding any more new features is one thing.  Actually testing
> those new features, and regression-testing old features, and
> fixing known bugs are something else again.

If you expect from the pretesters a thorough testing of Emacs, you need
a *very* long pretest phase (á la RMS). It is much more effective to
release the beast on a "good enough" (**) state and wait for the bug
reports from the multitude of users. Then fix those bugs and do a point
release. Conservative users can wait for the dot release, which I'll bet
that it will happen sooner than the "long pretest" release. And will be
more stable too.


(*) After using the development version of Emacs for 10+ years, I can
say that it is one of the most reliable software packages I ever
installed on any of my machines.

(**) No critical bugs, no significant regressions.




  reply	other threads:[~2014-02-10  2:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-10  0:06 Release date of Emacs 24.4? Jai Dayal
2014-02-10  1:19 ` Óscar Fuentes
2014-02-10  1:39   ` Drew Adams
2014-02-10  2:21     ` Óscar Fuentes [this message]
2014-02-10  3:42   ` Eli Zaretskii
2014-02-10 13:38 ` Stefan Monnier
2014-02-10 14:23   ` Søren Pilgård
2014-02-10 15:18     ` Jai Dayal
2014-02-10 17:07       ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lhxjbtc0.fsf@wanadoo.es \
    --to=ofv@wanadoo.es \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.