From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Move to a cadence release model? Date: Tue, 10 Nov 2015 19:11:54 +0200 Message-ID: <831tbxn5id.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1447175531 8928 80.91.229.3 (10 Nov 2015 17:12:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Nov 2015 17:12:11 +0000 (UTC) Cc: emacs-devel@gnu.org To: John Yates Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 10 18:12:03 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 1ZwCSg-0006C0-Cl for ged-emacs-devel@m.gmane.org; Tue, 10 Nov 2015 18:12:02 +0100 Original-Received: from localhost ([::1]:34327 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwCSg-0005Dt-1z for ged-emacs-devel@m.gmane.org; Tue, 10 Nov 2015 12:12:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37229) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwCSb-0005DN-D3 for emacs-devel@gnu.org; Tue, 10 Nov 2015 12:11:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwCSY-0007kG-Ld for emacs-devel@gnu.org; Tue, 10 Nov 2015 12:11:57 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:59634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwCSY-0007k4-D0 for emacs-devel@gnu.org; Tue, 10 Nov 2015 12:11:54 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NXL00M00ZJR2000@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Tue, 10 Nov 2015 19:11:52 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NXL00L2NZRRT270@a-mtaout22.012.net.il>; Tue, 10 Nov 2015 19:11:52 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:193888 Archived-At: > Date: Tue, 10 Nov 2015 08:57:07 -0500 > From: John Yates > > 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.