unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Carsten Mattner'" <carstenmattner@googlemail.com>,
	"'Eli Zaretskii'" <eliz@gnu.org>
Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: RE: Periodical releases
Date: Mon, 2 Jan 2012 11:05:40 -0800	[thread overview]
Message-ID: <71588355363047528F16FE989690A488@us.oracle.com> (raw)
In-Reply-To: <CACY+Hvofgt85mHk=LKapqKrnXLyDu9wT+kd8TZ=mJP4qSSMMUQ@mail.gmail.com>

> Don't wait until "perfection" and release trunk more often
> with bug releases if needed. 

No, no, no, please.  Just the opposite.
Bake Emacs _more_ fully before releasing it.

Get it right.  Document it well.  Mention all user-visible changes in NEWS.  Fix
outstanding bugs.

Richard had exactly the right approach to releasing Emacs, IMO.  He was attacked
by some because they felt the release cycle was too short.  I, for one,
appreciated his thoroughness and insistence on high quality.

> Emacs trunk has never been unstable for me.

Oh.  So please continue to use the trunk.

It's been quite unstable (not to mention incomplete) at various times for
others; believe me.  And that's been true forever.  It's normal.  To expect
anything else is naive, IMHO.

> I'm even using the NS port and it's still stable.

So please continue to use it.

> I would have less of a need to build emacs manually if
> there were more release and therefore standard emacs
> Linux distros was more up to date.

The problem you raise here is apparently one of the difficulty/nuisance of
building Emacs.  It is not about how often to publish releases.

Publishing non-release MS Windows binaries periodically has been _very_ helpful
(thank you again to those who have created and posted the builds).  At least on
that platform, that is a solution to the problem you raise.

If the same cannot be done for other platforms then the solution would be to
somehow simplify the difficulty/nuisance of building Emacs on those platforms.

But in no case should that difficulty/nuisance of building be an excuse for
releasing the product before it is fully baked.




  parent reply	other threads:[~2012-01-02 19:05 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-31 12:00 Periodical releases Carsten Mattner
2012-01-01 22:41 ` Stefan Monnier
2012-01-02 10:40   ` Carsten Mattner
2012-01-02 11:36     ` Eli Zaretskii
2012-01-02 12:57       ` Carsten Mattner
2012-01-02 17:31         ` Eli Zaretskii
2012-01-02 19:05         ` Drew Adams [this message]
2012-01-02 19:54           ` chad
2012-01-02 21:36             ` Carsten Mattner
2012-01-02 20:29           ` Eric Schulte
2012-01-02 21:31             ` Carsten Mattner
2012-01-02 20:41           ` Lluís
2012-01-02 21:23           ` Carsten Mattner
2012-01-02 22:14             ` Drew Adams
2012-01-02 22:27               ` Carsten Mattner
2012-01-05  2:34           ` Dave Abrahams
2012-01-05  2:58             ` Chong Yidong
2012-01-05  3:36               ` Dave Abrahams
2012-01-05  4:23                 ` Óscar Fuentes
2012-01-05 13:25                 ` Eli Zaretskii
2012-01-05 13:41                   ` Dave Abrahams
2012-01-05  9:31               ` Bastien
2012-01-05 10:11                 ` Leo
2012-01-05 11:31                   ` Carsten Mattner
2012-01-05 12:56                   ` Jambunathan K
2012-01-05 14:00                     ` Leo
2012-01-05 14:30                       ` Jambunathan K
2012-01-05 11:28                 ` Carsten Mattner
2012-01-05 14:18                   ` Eric Schulte
2012-01-05 11:33                 ` Carsten Mattner
2012-01-05  5:43             ` Eli Zaretskii
2012-01-05 12:20               ` Dave Abrahams
2012-01-05 15:34             ` Drew Adams
2012-01-03 22:23     ` Stefan Monnier
2012-01-03 18:18 ` What's in a feature? (was: Periodical releases) Bastien
2012-01-04  3:24   ` Stephen J. Turnbull
2012-01-04 10:03     ` What's in a feature? Bastien
2012-01-04 12:43       ` Juanma Barranquero

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=71588355363047528F16FE989690A488@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=carstenmattner@googlemail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).