From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Next release from master Date: Wed, 10 Feb 2016 19:35:32 -0800 Message-ID: <56BC0184.2040907@dancol.org> References: <8qegda3kfg.fsf@fencepost.gnu.org> <83h9i695n5.fsf@gnu.org> <87si118q6e.fsf@gnus.org> <877fid5u3e.fsf@gmx.us> <87bn7pwgaj.fsf@wanadoo.es> <87y4atqq25.fsf@gnus.org> <877fidwaka.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oOP7EikwbJethjm4HOfCFnkuG4XR43qHI" X-Trace: ger.gmane.org 1455161771 22172 80.91.229.3 (11 Feb 2016 03:36:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Feb 2016 03:36:11 +0000 (UTC) To: =?UTF-8?Q?=c3=93scar_Fuentes?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 11 04:36:07 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 1aTi34-000597-HB for ged-emacs-devel@m.gmane.org; Thu, 11 Feb 2016 04:36:06 +0100 Original-Received: from localhost ([::1]:45763 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTi33-0000fZ-Rb for ged-emacs-devel@m.gmane.org; Wed, 10 Feb 2016 22:36:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42225) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTi2p-0000fS-Ii for emacs-devel@gnu.org; Wed, 10 Feb 2016 22:35:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTi2l-0000RA-6C for emacs-devel@gnu.org; Wed, 10 Feb 2016 22:35:51 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:45306) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTi2k-0000Pn-SG for emacs-devel@gnu.org; Wed, 10 Feb 2016 22:35:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=6kPSDJXZjf2cyGFyvUJGhwwZWEJZiBGQxvUNasN5RWA=; b=n4Sj6UJtPAriiSjaReshtvQD5izkWYVidET0ImA3x8TxEI6JPx17Wt91i9lKW0L9q+0wgEL35tdQXw5RXDO9lrJnqD+6+TXhcSOlnDv2VYpRQ1Ce0/tGzLS8k5/nawvD5qVOx6mPCIzaoEG4x1cNqH1cnQ7tWmMPwxXgO2rkhVHJtQrEb/sOTEA9cdhJzu8JPTAiPQ2Gugwdl9Sfu2GzkqHIjbmGuGwl1IZR+mq7mEahi57Hf5a4iczruk9BOfDjfpNZgvC48wsRASIL1cOH3C5xp9YWVvqOXcmOrAwvtmWf1NH4U/nQrORY8RxkDpwiESLbO5J66jf8cgZLQYL3VQ==; Original-Received: from [2620:10d:c090:180::1:9073] (helo=[IPv6:2620:10d:c081:1103:2ab2:bdff:fe1c:db58]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aTi2c-0005rB-Po; Wed, 10 Feb 2016 19:35:38 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 In-Reply-To: <877fidwaka.fsf@wanadoo.es> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:199734 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oOP7EikwbJethjm4HOfCFnkuG4XR43qHI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/09/2016 06:42 PM, =D3scar Fuentes wrote: > Lars Ingebrigtsen writes: >=20 >> Emacs is an editor. When introducing new features, the trivial thing = to >> test is whether "it works". The complicated thing, and that needs man= y >> eyes, is whether something "works right". Only humans can say whether= a >> feature feels like it's getting in the way of getting things done, or >> whether it feels like the right thing to do. >=20 > Exactly. And developing features on `master' entirely bypasses the "it > works" phase, and that is a recipe for disaster. A dangerous change > should be on a branch until "it works" (*), then merged to see if it > "works right" (**). If the developer recruits some volunteers to see if= > it "works right" for them before the merge, that's even better. I see no need for such caution on the master branch. It's just as easy to revert a broken feature as it is to add one in the first place. I'm in favor of developing directly on master. --oOP7EikwbJethjm4HOfCFnkuG4XR43qHI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWvAGEAAoJEN4WImmbpWBlR6gP/2xEaufNrsDnS8dssZWGW/fG yJCSOTT+CzRAdPsXPNwHj7rkX/TRu1vJ/odeKz1z06nEiFyh+aZDKDdQ3biP/5GP /moeoBZeCFMlXnfe+cauAy3ionK/9HQ0W3k111qnQhcH06f45Fon5s+65UCyaw+L Ne5yh31cVXFgfT1L7QlRmx8YC7KHj7ZnoY5EaVjbN4LcbubrLxgf/FRfmTc9KPBu 02PgrexdFj9swEClfmhrWHFSLY0SyXO/bYxiopjsBI5HX8Q65TCwtnDo8ihRfwqo +yofBmTS7qxM72PjcSzxh2iYjQWhxxlG/2dkg+efdor2+FFCfPUmdu27l+qJO+Z2 7M0Dzo8sHdds7NpXhKVyhdkgwnteEF5DnBDiN/HC/sPevmWw6cI6T17uGa/DtkGr bu5U4KanvA3GVEY/qPHToPJpyDN+6S9CRWPbkJp8RZxL86gpJb5iLtL15iBjw5hQ ZzJFL1UP2+3SYyoxhPUHpsaa4qTpsURDPsIV3ZIZ06u77jwvbSVt3Ctq/vLq74Kk 2uqJaOEPzJR4mfeJa4uKo3h2jLNwUCkE6PhmY29sjbMyoCTeLu/LirqtXqU4ts6V wna5wugt79kpWsPzrqA/jC7ySr2FjimH/V4TulU96+qqNgnM622fYmITvLhWCY9W EwmK8Cvy0wkMetevylJl =4XPL -----END PGP SIGNATURE----- --oOP7EikwbJethjm4HOfCFnkuG4XR43qHI--