Re: Move to a cadence release model?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 10 Nov 2015 08:57:07 -0500
> From: John Yates <john@yates-sheets.org>
> 
> With a new master at the helm and various changes being contemplated I would
> like to see some discussion of moving to a cadence release model.
> 
> I have been impressed with open source projects that have made the
> change.

Which ones?

> I am now employed at Mathworks which ships mission critical software
> to very large enterprise customers on a 6 month cadence.
> 
> The biggest shift I see is away from wondering when the correct collection of
> features, bug fixes, whatever have been accumulated to whether those that have
> been accumulated are individually sufficiently cooked to ship. Developers feel
> less urge to squeeze a not fully baked feature into the current release when
> they can count on the next opportunity being only a cadence interval in the
> future.

AFAIK, cadence release model requires development that is planned in
advance, and then actively managed to make sure the features planned
for the next release are ready on time.

I don't know how things work at Mathworks, but I'm guessing there are
staff and processes in place to enable that.  There's probably someone
whose job is to collect proposals for new features, either from users,
or from developers, or from significant improvements in relevant
algorithms, etc.  Then there's a process that distills these proposals
into requirements for new features, prioritizes those requirements,
and decides on the schedule they will be implemented.  Then these
plans are given to developers, and there are procedures that manage
the development; e.g., if it turns out there's not enough manpower,
someone goes out and hires some more, or takes other managerial
actions.  This management requires, among other things, continuous
collection of status of each developer and tight control of their
advances.  Last, but not least, you have a known number of man-months
per month at your disposal, people who work day in and day out, which
allows reasonably accurate estimations of when each feature can be
ready to ship.

Is the above anywhere close to what happens at Mathworks?  If not,
perhaps you could describe the process that supports your cadence
model.  Because I don't know how it can be done without something like
that.

Cadence model can also work for FLOSS projects, provided that the
development team can count on their resources to enable a steady
stream of improvements.  E.g., there are projects where the core
developers get paid to work on the otherwise Free Software package
(GDB is one such package, but even GDB doesn't always succeed to
release according to plan).

And maybe there are other arrangements that might enable cadence.  The
key is the ability of the project leadership to ensure steady flow of
improvements and new features.  Without that, cadence model will
simply not work, because it makes very little sense to take a snapshot
of the main development branch at some arbitrary point in time and
declare it to be the future release.

Now, we don't have any of that in Emacs.  Some of what I mentioned
above might be possible, if we find the right people to do the job.
Other parts are IMO impossible even in principle: e.g., who of us
could commit to some minimal amount of hours he/she can work on Emacs
each day?  Without such a basic prerequisite, how could anyone plan
ahead Emacs development and ensure that the next release will be
meaningful to our users?

And one more thing, about the "next opportunity": this only works if
that opportunity is close.  If the next major Emacs release is 3 years
away, no one will want to wait, and it will be unreasonable for us to
ask them to wait.  It is much more reasonable for _us_ to wait for a
few weeks, and allow that feature to be finished in time for the
release.