all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: John Yates <john@yates-sheets.org>
Cc: xfq.free@gmail.com, rms@gnu.org, emacs-devel@gnu.org
Subject: Re: Move to a cadence release model?
Date: Wed, 11 Nov 2015 17:37:32 +0200	[thread overview]
Message-ID: <837flolf7n.fsf@gnu.org> (raw)
In-Reply-To: <CAJnXXoi0_zAJqMUDN+gB8arRJEkbpkqn6y53HS9qm4Sw2C6V2Q@mail.gmail.com>

> Date: Tue, 10 Nov 2015 20:55:59 -0500
> From: John Yates <john@yates-sheets.org>
> 
> Re Eli's points: In my short time at Mathworks it is clear to me that the model is very different from what he imagines.  At Mathworks a culture of cadence-base release starts with an absolute awareness that no one knows what will be in the next release.

I sincerely doubt that.  Someone in the company's management must
know.  Moreover, someone must actively _control_ that.  You cannot run
a successful business any other way.

> Concretely that translates into _never_ making such commitments to customers.

I never said it should be known to customers.  It should, however, be
known internally.  Otherwise, Mathworks is just another chaotic firm
which we have nothing to learn from (and can actually teach them some ;-).

> I am told that what corresponds to "roadmap presentations" come down to describing areas that the company views as strategic and hence where it is investing development resources.

There you go: we don't have any such roadmap in Emacs.  And I actually
very much doubt if we can practically have one.  At least all past
attempts to start something like that failed spectacularly.  Countless
discussions about adding WYSIWYG word-processor like editing features,
developing an Emacs IDE, etc. -- these all are attempts to set just
the first milestone on that roadmap.  They all eat dust every single
time the issues are raised here.  Doesn't that say something about our
culture and preferences?

> The clear message is that shipping a high-quality product on a predictable schedule is more important than delaying the release or shipping something buggy.

Emacs doesn't "ship buggy", so that's not the issue here.

As for predictable release schedule, whether this is important should
be based on user surveys.  Did someone make such surveys for Emacs?  I
don't think so.  FWIW, it makes little sense to me to install a new
non-bugfix release of a major package such as Emacs without getting
significant new features, but I'm just one user, and most probably not
the typical one.

In any case, if we want to focus on frequent high-quality releases, we
should work on our QA.  That's the point Óscar was making: our QA is
abysmally inadequate.

> rapid availability of bug fix releases containing _nothing_ but high priority bug fixes.

That is relatively much easier, and we already tried that on the
Emacs-24 branch: the last bugfix release was out the door in about 10
days since the first pretest (which we declared an RC).  But this is
only possible on the release branch, and only if we allow absolutely
nothing on that branch except relatively safe bug fixes.

> I have been thinking about the difference between Emacs' development culture and that of project with a strong commitment to maintaining a cadence.  My conclusion is that it comes down to the effort put into keeping the master branch so healthy that a release branch could be cut at nearly any moment.  Inevitably this comes with a strong emphasis on code review, gatekeeping and usually continuous testing.  The Linux kernel is somewhat atypical in having its gatekeeping function  entrusted entirely to humans (Linus' lieutenants and their underlings).  (I am unfamiliar with Firefox.  I did read https://www.mozilla.org/en-US/about/governance/policies/commit/access-policy/ but failed to get a good sense of how things work there.)  All of the remaining projects (Chromium, LibreOffice and OpenStack) use gerrit to enforce a review processes (and to support continuous integration testing).  The important part of all of these review cultures is that work _must_ be presented in reviewable uni

So we essentially agree: switching to any cadence model requires deep
changes in how Emacs development works, which in turn requires a much
larger core development team and a very different organization of that
team.  E.g., a gatekeeper model won't work without a gatekeeper.  We
can try working towards such new models, if we believe we can achieve
them.  But until we get close to that goal, discussing such radically
different models will remain a pipe dream at best.

> Re current pattern of 6 month code freeze: This seems to be a manifestation of that fact that once a sufficient collection of new features have been accumulated we recognize in our heart of hearts that our code is not ready for release.  At a minimum it has not necessarily been built on all of the platforms we claim to support, various feature have received waivers (hence are incomplete) and lots of documentation remains to be written.  Moving more rapidly from cutting a release branch to asserting a release-ready tarball requires addressing those cultural patterns.

There is no 6-month code freeze.  There are long pretest periods for
major version releases.  Emacs 21.1, which included a complete rewrite
of the display engine and many other significant changes, took 11
months since the first pretest till the release.  Emacs 22.1 took 7.5
months, Emacs 23.1 5 months, Emacs 24.1 8.5 months.  A large portion
of that time is spent updating the documentation to match the changes,
especially documenting the new features, and then proof-reading the
manuals.  (I'm guessing at Mathworks you don't have developers writing
and proof-reading the documentation, you have special staff for that.
We don't have such luxury.)  Slashing those months-long pretest
periods means requesting that every user-visible change be accompanied
by the corresponding documentation changes -- are we prepared to do
that?  Do we have enough people in place to review and comment on
those documentation changes if and when they do come?  Don't forget
that some of us cannot write good English documentation and/or don't
command written technical English enough to produce something decent.
And I didn't even start talking about how many of us _want_ to deal
with documentation even if their English is fine.

The other reason for the long pretests is indeed the need to test the
upcoming release on a wide array of different platforms and system
configurations.  We used to have a group of pretesters who represented
the supported platforms, and who were instrumental in that process.
We no longer seem to have such a group, and the platforms we care
about changed anyway.  As result, our coverage of the possible
configurations is mostly random, and we can no longer be sure that a
long enough pretest period will shake out enough bugs.  Note that it
is not enough to just build on a platform, you must actually use Emacs
there to find bugs.  And since a typical user uses only a small
fraction of Emacs features, a single tester per platform/configuration
is not enough for thorough testing.  Some work in that area is needed,
e.g. to identify the features which might be platform-dependent
(example: file notifications), and then compile a list of platforms
that share the same implementation of a given feature.  Then we need a
few testers for each such group, and we need to inform them about each
pretest (there used to be a mailing list for that) and be sure to
collect their reports.

Lots of job opportunities there, and too few volunteers...




  parent reply	other threads:[~2015-11-11 15:37 UTC|newest]

Thread overview: 139+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-10 13:57 Move to a cadence release model? John Yates
2015-11-10 14:28 ` John Wiegley
2015-11-10 16:42   ` Eli Zaretskii
2015-11-10 17:03     ` John Wiegley
2015-11-11  0:17       ` Release process (was Re: Move to a cadence release model?) Stephen Leake
2015-11-11  0:24         ` John Wiegley
2015-11-11  3:45         ` Eli Zaretskii
2015-11-11 10:45           ` Stephen Leake
2015-11-11 15:43             ` Eli Zaretskii
2015-11-11 20:39               ` Too few people taking care of bug reports, was: " Dmitry Gutov
2015-11-11 20:50                 ` Too few people taking care of bug reports, John Wiegley
2015-11-11 21:03                   ` Dmitry Gutov
2015-11-11 21:06                     ` John Wiegley
2015-11-11 21:14                   ` Eli Zaretskii
2015-11-11 21:10                 ` Too few people taking care of bug reports, was: Re: Release process (was Re: Move to a cadence release model?) Eli Zaretskii
2015-11-11 21:15                   ` Too few people taking care of bug reports, John Wiegley
2015-11-11 21:27                     ` Eli Zaretskii
2015-11-11 21:23                   ` Too few people taking care of bug reports, was: Re: Release process (was Re: Move to a cadence release model?) Dmitry Gutov
2015-11-11 21:30                     ` Eli Zaretskii
2015-11-11 21:31                       ` Dmitry Gutov
2015-11-11 21:42                     ` Eli Zaretskii
2015-11-11 21:54                       ` Dmitry Gutov
2015-11-11 23:06               ` bug policy (was Re: Release process) Stephen Leake
2015-11-12 16:12                 ` Eli Zaretskii
2015-11-12 16:39                   ` John Wiegley
2015-11-12 17:36                     ` Eli Zaretskii
2015-11-12 17:50                       ` John Wiegley
2015-11-12 18:04                         ` Eli Zaretskii
2015-11-11 16:39             ` Release process (was Re: Move to a cadence release model?) John Wiegley
2015-11-12  8:19               ` Xue Fuqiao
2015-11-17  0:09                 ` Xue Fuqiao
2015-11-12  8:15             ` Xue Fuqiao
2015-11-10 14:32 ` Move to a cadence release model? Alan Mackenzie
2015-11-10 17:13   ` Eli Zaretskii
2015-11-10 17:11 ` Eli Zaretskii
2015-11-10 17:37   ` Óscar Fuentes
2015-11-10 17:44     ` Automate Emacs UI testing? (was: Move to a cadence release model?) John Wiegley
2015-11-10 18:01       ` Automate Emacs UI testing? Ashton Kemerling
2015-11-10 18:02       ` Automate Emacs UI testing? (was: Move to a cadence release model?) Eli Zaretskii
2015-11-10 19:16       ` Automate Emacs UI testing? joakim
2015-11-10 19:37         ` John Wiegley
2015-11-11 16:59         ` Richard Stallman
2015-11-11 17:18           ` joakim
2015-11-11 23:27             ` Richard Stallman
2015-11-12  2:26               ` official Emacs Docker image (was: Automate Emacs UI testing?) Ted Zlatanov
2015-11-12 15:49                 ` official Emacs Docker image Nic Ferrier
2015-11-12 21:01                   ` Ricardo Wurmus
2015-11-12 22:31                 ` official Emacs Docker image (was: Automate Emacs UI testing?) Richard Stallman
2015-11-12 23:32                   ` official Emacs Docker image joakim
2016-07-06 15:22                   ` Ted Zlatanov
2016-07-07 21:56                     ` Richard Stallman
2016-07-08 13:36                       ` Ted Zlatanov
2016-07-09 16:54                         ` Richard Stallman
2016-07-09 23:04                           ` Ted Zlatanov
2016-07-10 14:25                             ` Richard Stallman
2016-07-12 22:45                             ` John Wiegley
2016-07-13 13:12                               ` Richard Stallman
2016-07-13 16:34                                 ` John Wiegley
2016-12-30  0:10                                   ` Richard Stallman
2016-12-30  0:53                                     ` John Wiegley
2016-12-30 21:36                                       ` Richard Stallman
2016-12-30 22:01                                         ` joakim
2016-12-30 22:08                                         ` John Wiegley
2016-12-31 18:25                                           ` Richard Stallman
2017-01-27 14:56                                             ` Ted Zlatanov
2017-01-27 19:45                                               ` Filipe Silva
2017-01-30 14:36                                                 ` Ted Zlatanov
2017-01-30 17:10                                                 ` Ricardo Wurmus
2017-01-30 17:44                                                   ` Ted Zlatanov
2017-01-31  0:14                                                     ` Filipe Silva
2017-01-31 14:32                                                       ` Ted Zlatanov
2017-02-01  3:03                                                         ` Richard Stallman
2017-02-01 15:25                                                           ` Ted Zlatanov
2017-02-02  2:53                                                             ` Richard Stallman
2017-02-02  5:13                                                               ` Mike Gerwitz
2017-02-02 14:21                                                               ` Ted Zlatanov
2017-02-03  7:00                                                                 ` Stefan Reichör
2017-02-03 11:18                                                                   ` Filipe Silva
2017-02-04  2:56                                                                     ` Mike Gerwitz
2017-02-03 13:45                                                                   ` Ted Zlatanov
2017-02-03 21:59                                                                     ` Richard Stallman
2017-02-03 23:38                                                                       ` Ted Zlatanov
2017-02-03 23:54                                                                         ` Jean-Christophe Helary
2017-02-04  0:37                                                                           ` Filipe Silva
2017-02-04  1:12                                                                             ` Jean-Christophe Helary
2017-02-04  1:32                                                                               ` Filipe Silva
2017-02-04 23:52                                                                               ` Richard Stallman
2017-02-05  0:24                                                                                 ` Jean-Christophe Helary
2017-02-04 23:54                                                                             ` Richard Stallman
2017-02-04  3:11                                                                         ` Mike Gerwitz
2017-02-04  4:13                                                                           ` Ted Zlatanov
2017-02-04  4:47                                                                             ` Mike Gerwitz
2017-02-06 10:49                                                                               ` Giuseppe Scrivano
2017-02-13  8:37                                                                                 ` Richard Stallman
2017-02-13  9:55                                                                                   ` Giuseppe Scrivano
2017-02-14  0:48                                                                                     ` Richard Stallman
2017-02-14  2:07                                                                                       ` Mike Gerwitz
2017-02-14  2:04                                                                                 ` Mike Gerwitz
2017-02-04 23:54                                                                             ` Richard Stallman
2017-02-05  0:47                                                                               ` Ted Zlatanov
2017-02-04 23:48                                                                 ` Richard Stallman
2017-01-28  2:18                                               ` Richard Stallman
2017-02-21 15:01                                               ` Philippe Vaucher
2017-03-02 15:03                                                 ` Ted Zlatanov
2017-03-03 10:09                                                   ` Philippe Vaucher
2017-03-03 10:15                                                     ` Philippe Vaucher
2017-03-08 20:30                                                       ` Philippe Vaucher
2017-03-13 10:03                                                         ` Philippe Vaucher
2018-04-04 18:33                                                         ` Philippe Vaucher
2016-12-31 22:04                                         ` Ricardo Wurmus
2017-01-01  5:39                                           ` Elias Mårtenson
2017-01-01  9:03                                             ` Ricardo Wurmus
2017-01-01 10:15                                               ` Elias Mårtenson
2017-01-06 15:56                                                 ` Ricardo Wurmus
2017-01-07 23:19                                                   ` Philippe Vaucher
2016-12-31  1:22                                       ` Yann Hodique
2016-12-31  2:08                                         ` John Wiegley
2017-01-28 11:06                                       ` Alex Bennée
2016-12-31 10:11                                     ` Philippe Vaucher
2016-07-13 14:41                               ` Ted Zlatanov
2015-11-12 11:36         ` Automate Emacs UI testing? Mathieu Lirzin
2015-11-12 11:43           ` joakim
2015-11-10 18:20 ` Move to a cadence release model? Richard Stallman
2015-11-10 23:50   ` Xue Fuqiao
2015-11-10 23:58     ` John Wiegley
2015-11-11  1:55       ` John Yates
2015-11-11  9:02         ` Xue Fuqiao
2015-11-11 15:37         ` Eli Zaretskii [this message]
2015-11-12 22:35         ` Richard Stallman
2015-11-11 15:49       ` Eli Zaretskii
2015-11-12 11:27         ` Stelian Iancu
2015-11-12 16:22           ` Eli Zaretskii
2015-11-12 16:44             ` Stelian Iancu
2015-11-12 16:57               ` Eli Zaretskii
2015-11-11 15:48     ` Eli Zaretskii
2015-11-12  7:23       ` Xue Fuqiao
2015-11-12  7:37         ` Xue Fuqiao
2015-11-12 16:15         ` Eli Zaretskii
2015-11-20  3:02 ` 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=837flolf7n.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=john@yates-sheets.org \
    --cc=rms@gnu.org \
    --cc=xfq.free@gmail.com \
    /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.