On Sun, Dec 4, 2016 at 6:12 PM, Daniel Colascione <dancol@dancol.org> 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