From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Yates Newsgroups: gmane.emacs.devel Subject: Re: Move to a cadence release model? Date: Tue, 10 Nov 2015 20:55:59 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b15b215b6f18805243a204f X-Trace: ger.gmane.org 1447206984 20808 80.91.229.3 (11 Nov 2015 01:56:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2015 01:56:24 +0000 (UTC) To: Xue Fuqiao , Richard Stallman , Emacs-devel , John Yates Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 11 02:56:22 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZwKe4-00074R-BA for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 02:56:20 +0100 Original-Received: from localhost ([::1]:37157 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwKe3-00059B-HP for ged-emacs-devel@m.gmane.org; Tue, 10 Nov 2015 20:56:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38121) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwKdo-00058t-4u for emacs-devel@gnu.org; Tue, 10 Nov 2015 20:56:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwKdm-0002ml-7L for emacs-devel@gnu.org; Tue, 10 Nov 2015 20:56:04 -0500 Original-Received: from mail-pa0-x232.google.com ([2607:f8b0:400e:c03::232]:34767) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwKdj-0002m2-LY; Tue, 10 Nov 2015 20:55:59 -0500 Original-Received: by padhx2 with SMTP id hx2so15253270pad.1; Tue, 10 Nov 2015 17:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=V0XId7dpek9IA67DnNnncmoQUQFnCf6l5/fjgXoHs/I=; b=cW4OaC7MjZH80m5vNgIDIEqXwV/Gar13UWttQKLlx5ne28plV6Eai4YL3hO0tSrAkq 3PX4YaAYQCFpr1RwWiriT8f4Zz3LFajV2QxEaRHz/WaHdAYMRspBVgBySaFfJ8titR9o tR4cK8ucznj+4XSVG0BTNLLJ9vWLdHJ/APAkWqkFNwZUSebo98DRWHcBftFfGXDqmmAQ c5JCan0ux2SIPCI9p58XMRJVg4NoiOMyAIpVWQtxYiRDzS6/wOsX3Yab1/qPk4OA5FC/ FQAFll8LFikpHCBwVdgDr21v5fT4q+4v3lGj4B9mivREzGmvAuHi3GDMZCrL5PjGUCtI TRAw== X-Received: by 10.67.1.103 with SMTP id bf7mr10244566pad.147.1447206959114; Tue, 10 Nov 2015 17:55:59 -0800 (PST) Original-Received: by 10.66.159.101 with HTTP; Tue, 10 Nov 2015 17:55:59 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: NHidFY-LoBIgydAf89hm75-Lu3A X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194030 Archived-At: --047d7b15b215b6f18805243a204f Content-Type: text/plain; charset=UTF-8 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 --047d7b15b215b6f18805243a204f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mea culpa.=C2=A0 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.

<= span style=3D"font-size:12.8px">I have gone back and tried to identify smal= ler projects which have made such a change.=C2=A0 To my shame I am unable t= o find any.=C2=A0 Not say that they do not exist (I am sure that they do) b= ut I am unable to formulate a google query that turns any up. =C2=A0(It doe= s not help that there is a prominent software company named Cadence Design = Systems :-).=C2=A0 That said I would add to Xue Fugiao's list OpenStack= (6 month cadence).

<= /span>
Re Eli's points: In m= y short time at Mathworks it is clear to me that the model is very differen= t from what he imagines.=C2=A0 At Mathworks a culture of cadence-base relea= se starts with an absolute awareness that no one knows what will be in the = next release.=C2=A0 Concretely that translates into _never_ making such com= mitments to customers.=C2=A0 I am told that what corresponds to "roadm= ap presentations" come down to describing areas that the company views= as strategic and hence where it is investing development resources.=C2=A0 = I have not attended such a presentation (I am, after all, a lowly engineer)= .=C2=A0 Still I have been lead to believe that such presentations are quite= honest about relative levels of investment and priorities attached to vari= ous development activities.=C2=A0 The customers in turn are=C2=A0knowledgea= ble=C2=A0enough to understand that - to the extant that development resourc= es are fungible - under some circumstance resources may be pulled from lowe= r priority work to accelerate delivery of higher priority work.=C2=A0 Eli i= s correct that there is some attempt at the start of a development cycle to= synchronize and coordinate activities that involve cross-group dependencie= s.=C2=A0 But what has struck me most strongly, based on more than 40 years = prior experience in commercial software development, is how readily feature= s that had been on a glide path toward shipment in a given release can get = cut.=C2=A0 The clear message is that shipping a high-quality product on a p= redictable schedule is more important than delaying the release or shipping= something buggy.=C2=A0 If a feature was nearly ready for this release then= surely it will be in truly great shape for the release 6 months later.=C2= =A0 So why take a chance?=C2=A0 The other part of taking care of customers = is quick publication of descriptions of any bugs that do make it into the f= ield, including either publication of work-arounds where appropriate and wh= en necessary rapid availability of bug fix releases containing _nothing_ bu= t high priority bug fixes.

I have been thinki= ng about the difference between Emacs' development culture and that of = project with a strong commitment to maintaining a cadence.=C2=A0 My conclus= ion 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.=C2=A0 I= nevitably this comes with a strong emphasis on code review, gatekeeping and= usually continuous testing.=C2=A0 The Linux kernel is somewhat atypical in= having its gatekeeping function =C2=A0entrusted entirely to humans (Linus&= #39; lieutenants and their underlings). =C2=A0(I am unfamiliar with Firefox= .=C2=A0 I did read=C2=A0https://www.mozilla.org/en-US/about/= governance/policies/commit/access-policy/ but failed to get a good sens= e of how things work there.) =C2=A0All of the remaining projects (Chromium,= LibreOffice and OpenStack) use gerrit to enforce a review processes (and t= o support continuous integration testing).=C2=A0 The important part of all = of these review cultures is that work _must_ be presented in reviewable uni= ts.=C2=A0 No matter how good the work and no matter how great the reputatio= n 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=C2=A0digestible=C2=A0units.=C2=A0 Keeping the master branc= h ready for release also means not allowing incomplete work to get promoted= .=C2=A0 Hence none of these projects would deem=C2=A0acceptable=C2=A0code w= ithout supporting documentation or unit tests.=C2=A0 Absence of either woul= d be grounds for a failed review.

Re current = pattern of 6 month code freeze: This seems to be a manifestation of that fa= ct 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.= =C2=A0 At a minimum it has not necessarily been built on all of the platfor= ms we claim to support, various feature have received waivers (hence are in= complete) and lots of documentation remains to be written.=C2=A0 Moving mor= e rapidly from cutting a release branch to asserting a release-ready tarbal= l requires addressing those cultural patterns.

/john

--047d7b15b215b6f18805243a204f--