Re: Move to a cadence release model?

[John Yates <john@yates-sheets.org>]

[-- Attachment #1: Type: text/plain, Size: 4649 bytes --]

Mea culpa.  I let my enthusiasm get the better of me is when I wrote

> I have been impressed with open source projects that have made the change.

I have gone back and tried to identify smaller projects which have made
such a change.  To my shame I am unable to find any.  Not say that they do
not exist (I am sure that they do) but I am unable to formulate a google
query that turns any up.  (It does not help that there is a prominent
software company named Cadence Design Systems :-).  That said I would add
to Xue Fugiao's list OpenStack (6 month cadence).

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.  Concretely that translates into _never_
making such commitments to customers.  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.
I have not attended such a presentation (I am, after all, a lowly
engineer).  Still I have been lead to believe that such presentations are
quite honest about relative levels of investment and priorities attached to
various development activities.  The customers in turn
are knowledgeable enough to understand that - to the extant that
development resources are fungible - under some circumstance resources may
be pulled from lower priority work to accelerate delivery of higher
priority work.  Eli is correct that there is some attempt at the start of a
development cycle to synchronize and coordinate activities that involve
cross-group dependencies.  But what has struck me most strongly, based on
more than 40 years prior experience in commercial software development, is
how readily features that had been on a glide path toward shipment in a
given release can get cut.  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.  If a feature was nearly
ready for this release then surely it will be in truly great shape for the
release 6 months later.  So why take a chance?  The other part of taking
care of customers is quick publication of descriptions of any bugs that do
make it into the field, including either publication of work-arounds where
appropriate and when necessary rapid availability of bug fix releases
containing _nothing_ but high priority 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 units.  No matter how good the work and
no matter how great the reputation of the developer if what is offered for
review is too large or amorphous then it is entirely expected that it will
be reject with a request to break it up into more digestible units.
Keeping the master branch ready for release also means not allowing
incomplete work to get promoted.  Hence none of these projects would
deem acceptable code without supporting documentation or unit tests.
Absence of either would be grounds for a failed review.

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.

/john

[-- Attachment #2: Type: text/html, Size: 5414 bytes --]