From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philippe Vaucher Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Tue, 6 Dec 2016 11:38:32 +0100 Message-ID: References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <8360n6ruzu.fsf@gnu.org> <834m2nplmb.fsf@gnu.org> <83inr2oje6.fsf@gnu.org> <83bmwuogfb.fsf@gnu.org> <878trydrbo.fsf@red-bean.com> <83a8cem1eq.fsf@gnu.org> <83fum3lmag.fsf@gnu.org> <87y3zvehzm.fsf@dancol.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f403045e315850a5fe0542fb03c1 X-Trace: blaine.gmane.org 1481021265 32190 195.159.176.226 (6 Dec 2016 10:47:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Dec 2016 10:47:45 +0000 (UTC) Cc: kfogel@red-bean.com, Eli Zaretskii , Richard Stallman , Emacs developers To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 06 11:47:40 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cEDHe-0007C1-Sv for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2016 11:47:39 +0100 Original-Received: from localhost ([::1]:48911 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cEDHi-0007D6-J0 for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2016 05:47:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55715) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cEDAr-0002BD-VN for emacs-devel@gnu.org; Tue, 06 Dec 2016 05:40:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cEDAo-000306-Oc for emacs-devel@gnu.org; Tue, 06 Dec 2016 05:40:37 -0500 Original-Received: from mail-ua0-f175.google.com ([209.85.217.175]:34933) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cEDAf-0002pl-Gd; Tue, 06 Dec 2016 05:40:25 -0500 Original-Received: by mail-ua0-f175.google.com with SMTP id 12so377375939uas.2; Tue, 06 Dec 2016 02:40:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tg+DwPyvqCDR9g5p0x4ZQlqE4FBcQUT6AigZqFiwup0=; b=W7E7rOHkvPma92ckeC0iDcVSA5YmEtnU8VTMXkaeY45/5g/logkymsL738hzsaMZBF qvnsisZLrMqvx14gWtQj7ipP+kUd3z1j67eP6XBJQAw8I/GBMjW8AyE/QDfknOqusGqx RPvOFduQ0kyWWMLCJc8SutNeDYLO6Izid/WjJDEi3QgJoYpxGaRwndjH4wVCDcnCnO/1 zNU6SUjdPZVpFrFyZ8F+bGv6gBJ7GHOfTPdII0I6DuCm3Gc0vhAL/fe+6Oz9+eYwd8MM Cik1cTfIPgkB88suapnOq2YhXIPb90unb8sLKwFc5D+G/2U/ZyWruVlRYWqzPOrD77+o pPPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tg+DwPyvqCDR9g5p0x4ZQlqE4FBcQUT6AigZqFiwup0=; b=XaPVLgM2RAccrVbFRlsXxXGfrahbFeiQcJ6xiFkl9iSmbKkGvmYyGeyWZeN4IkmTbG druXQ5EHGqLyYVsOG1vyR/KZ0rdxn2XJFIzT5WjMirgm2I89w3xIRUORC4ZHyZcE342J 00ha0amflfzs9cC5rRn431JRcsqXmSO6onC330z32lMxOz9bKY0H//ajC4slIpETF5+b zJ5m/4zHYEicgzOYpb8a1SwLyEaACLK56D0eFGFwG3OYRef9xGWgRg9n42zwWFrDNf5I VViYZ8prvHYEsF7yW7PuVBb6LgdcW8s4Sx1OpZk+Gqzz3ynavpMpAi/4+eyVEdGcy1Ly 48og== X-Gm-Message-State: AKaTC02FabM9baWbxchchXcIkHjJk9sSIMETMfxw3JBybtkUmrrq/8D4sEhYNBgoLI60+ph1LqFzr/QKsWglKw== X-Received: by 10.176.16.2 with SMTP id f2mr39580041uab.49.1481020743393; Tue, 06 Dec 2016 02:39:03 -0800 (PST) Original-Received: by 10.103.125.149 with HTTP; Tue, 6 Dec 2016 02:38:32 -0800 (PST) In-Reply-To: <87y3zvehzm.fsf@dancol.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.217.175 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:210088 Archived-At: --f403045e315850a5fe0542fb03c1 Content-Type: text/plain; charset=UTF-8 On Sun, Dec 4, 2016 at 6:12 PM, Daniel Colascione wrote: > > We're talking about software. Anything we do, we can undo. (And please, > stop suggesting that we have some kind of duty to keep master absolutely > stable because someone, somewhere might make a master snapshot tarball > available for something. Why do we even have releases?) > Keeping master stable depends on the workflow wanted for Emacs... but in general, having a stable "master" is an accepted practice for any project of a reasonable size. The unstability can go in branches, that's what they are for. A stable master avoids all the unecesserary noise when "master breaks" because that affects everyone, and it allows for continuous integration as a bonus. There is a lot of different worflows available and I think it is our job to adapt to the project's workflow, or maybe propose a different workflow. Here are different typical used workflows: - only one master branch (small projects) - the git-flow workflow: one long-lived develop branch meant for development (unstable) from which features/releases branches might get branched from. The branch master is on the receiving end on the merges and anything merged to it should be stable (http://nvie.com/posts/a- successful-git-branching-model). Somewhat "long" release cycles. - the github workflow: master always "production ready", every features/bugfixes gets in a branch, and is merged when ready. Emphasis on short release cycles. - the git/kernel release model: many topical branches like "next", "pu" (proposed updates), "maint" (maintenance), etc. I think in general having a stable master is desired, now I agree it's not the end of the world if it gets unstable from time to time as long as it's fixed quickly. Philippe --f403045e315850a5fe0542fb03c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, Dec 4, 2016 at 6:12 PM, Daniel Colascione <dancol@dancol.org&g= t; wrote:

We're talking about software. Anything we do, we can undo.=C2=A0 (And p= lease,
stop suggesting that we have some kind of duty to keep master absolutely stable because someone, somewhere might make a master snapshot tarball
available for something.=C2=A0 Why do we even have releases?)

Keeping master stable depends on the workflow wanted= for Emacs... but in general, having a stable "master" is an acce= pted practice for any project of a reasonable size.

The unstability can go in branches, that's what they are for. A stabl= e master avoids all the unecesserary noise when "master breaks" b= ecause that affects everyone, and it allows for continuous integration as a= bonus.

There is a lot of different worflows avail= able and I think it is our job to adapt to the project's workflow, or m= aybe propose a different workflow.

Here are differ= ent typical used workflows:
  • only one master branch (small= projects)
  • the git-flow=C2=A0workflow: one long-lived develop branc= h meant for development (unstable) from which features/releases branches mi= ght get branched from. The branch master is on the receiving end on the mer= ges and anything merged to it should be stable (http://nvie.com/p= osts/a-successful-git-branching-model). Somewhat "long&q= uot; release cycles.
  • the github workflow: master always "produ= ction ready", every features/bugfixes gets in a branch, and is merged = when ready. Emphasis on short release cycles.
  • the git/kernel releas= e model: many topical branches like "next", "pu" (propo= sed updates), "maint" (maintenance), etc.=C2=A0
I think in general having a stable master is desired, now I agree it'= ;s not the end of the world if it gets unstable from time to time as long a= s it's fixed quickly.

Philippe
--f403045e315850a5fe0542fb03c1--