From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Next release from master Date: Wed, 10 Feb 2016 04:24:13 +0100 Message-ID: <87y4atuu1u.fsf@wanadoo.es> References: <8qegda3kfg.fsf@fencepost.gnu.org> <83h9i695n5.fsf@gnu.org> <87si118q6e.fsf@gnus.org> <877fid5u3e.fsf@gmx.us> <87bn7pwgaj.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1455074695 27549 80.91.229.3 (10 Feb 2016 03:24:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Feb 2016 03:24:55 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 10 04:24:47 2016 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 1aTLOY-0001pm-QF for ged-emacs-devel@m.gmane.org; Wed, 10 Feb 2016 04:24:46 +0100 Original-Received: from localhost ([::1]:35004 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTLOX-0001rY-Rz for ged-emacs-devel@m.gmane.org; Tue, 09 Feb 2016 22:24:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35409) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTLOK-0001rH-2z for emacs-devel@gnu.org; Tue, 09 Feb 2016 22:24:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTLOF-0000Tg-2e for emacs-devel@gnu.org; Tue, 09 Feb 2016 22:24:32 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:41091) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTLOE-0000TV-Sm for emacs-devel@gnu.org; Tue, 09 Feb 2016 22:24:27 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aTLOD-0001Td-4L for emacs-devel@gnu.org; Wed, 10 Feb 2016 04:24:25 +0100 Original-Received: from 1.red-83-38-42.dynamicip.rima-tde.net ([83.38.42.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Feb 2016 04:24:25 +0100 Original-Received: from ofv by 1.red-83-38-42.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Feb 2016 04:24:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 40 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 1.red-83-38-42.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:lcZgLaHaQgnFYi4hLCNK9Z7Q4sc= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:199667 Archived-At: Kaushal Modi writes: > On Tue, Feb 9, 2016 at 7:38 PM, Óscar Fuentes wrote: > >> What does "to be tested" mean here? Does it mean that the feature was >> not thoroughly tested by the developer yet? >> > > I use the dev builds of emacs as my daily driver. I keep the emacs-25 and > master builds ready at all times. For now, I am using emacs-25 as my daily > driver, mainly to test it thoroughly before its public release. But if some > bug creeps in that thwarts my day-job work, then I can report that and > switch to using the master branch build till the bug gets fixed (this is > just an example, I haven't needed to do that yet). I'm using emacs-dev since many years ago. Given its complexity, it is one of the most stable and reliable software packages I use. However, throwing half-working, untested, intrusive changes into master would change that for sure. For most part of the last year I was forced to use an old build of emacs-dev because someone changed a package which I depend on without a cursory testing. When the problem was reported, there was no positive response from the developer. It was not practical to revert the change because it was tangled with other unrelated changes across multiple packages. The problem stayed for months until somebody else who is familiar with the code fixed it enough to be usable again. In the meantime, emacs-dev had at least one less tester. This is a problem typical of projects who use the main branch as a sandbox. What keeps voluntary-based projects going is social conventions. Not stepping onto anybody else's toes is one of the most basic of them. That is helped by developing features in branches until one is honestly convinced that merging will not introduce known or suspected problems that harm other's work, and be quick to revert if some serious inconvenience cannot be fixed right away (which is facilitated by having a merge commit instead of multiple commits mixed with the rest of the VC history.) [snip]