Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Move to a cadence release model? Date: Wed, 11 Nov 2015 17:37:32 +0200 Lines: 155 Approved: news@gmane.org Message-ID: <837flolf7n.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1447256340 2787 80.91.229.3 (11 Nov 2015 15:39:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2015 15:39:00 +0000 (UTC) Cc: xfq.free@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: John Yates Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 11 16:38:50 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 1ZwXU1-0001b5-9Q for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 16:38:49 +0100 Original-Received: from localhost ([::1]:41298 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwXU0-0000ne-Ge for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 10:38:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50180) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwXTc-0000fn-7D for emacs-devel@gnu.org; Wed, 11 Nov 2015 10:38:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwXTY-000772-Tu for emacs-devel@gnu.org; Wed, 11 Nov 2015 10:38:24 -0500 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:53489) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwXTY-00076m-Fl; Wed, 11 Nov 2015 10:38:20 -0500 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NXN00500PQB5800@mtaout27.012.net.il>; Wed, 11 Nov 2015 17:32:45 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NXN00MKCPUK7V70@mtaout27.012.net.il>; Wed, 11 Nov 2015 17:32:44 +0200 (IST) Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.183 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:194070 Archived-At: > Date: Tue, 10 Nov 2015 20:55:59 -0500 > From: John Yates >=20 > Re Eli's points: In my short time at Mathworks it is clear to me th= at the model is very different from what he imagines. At Mathworks a= culture of cadence-base release starts with an absolute awareness th= at 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 ru= n 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 dow= n to describing areas that the company views as strategic and hence w= here it is investing development resources. There you go: we don't have any such roadmap in Emacs. And I actuall= y very much doubt if we can practically have one. At least all past attempts to start something like that failed spectacularly. Countles= s 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 ou= r culture and preferences? > The clear message is that shipping a high-quality product on a pred= ictable schedule is more important than delaying the release or shipp= ing 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 no= t the typical one. In any case, if we want to focus on frequent high-quality releases, w= e should work on our QA. That's the point =C3=83=C2=93scar was making:= our QA is abysmally inadequate. > rapid availability of bug fix releases containing _nothing_ but hig= h 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' developmen= t culture and that of project with a strong commitment to maintaining= a cadence. My conclusion is that it comes down to the effort put in= to keeping the master branch so healthy that a release branch could b= e cut at nearly any moment. Inevitably this comes with a strong emph= asis 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 underlin= gs). (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 tha= t 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 manif= estation of that fact that once a sufficient collection of new featur= es 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 featu= re have received waivers (hence are incomplete) and lots of documenta= tion remains to be written. Moving more rapidly from cutting a relea= se branch to asserting a release-ready tarball requires addressing th= ose 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 rewrit= e 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 writin= g 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 accompanie= d 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 represente= d 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 Emac= s there to find bugs. And since a typical user uses only a small fraction of Emacs features, a single tester per platform/configuratio= n 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 eac= h 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...