Re: Next release from master

[Barry Fishman]

On 2016-01-22 09:45:54 -0800, John Wiegley wrote:
>>>>>> Barry Fishman <address@hidden> writes:
>> I think you all are making things more difficult for yourselves.
>
> Hi Barry, I didn't really understand your e-mail; it sounded just as difficult
> as anything else that's been proposed. Could you summarize what exactly would
> make it an easier solution?
>
> In a sense "emacs-25" is the current master for our developers, with "master"
> collecting new features that we reject as too destabilizing for emacs-25. When
> we are done with "stabilizing mode", we'll go back to "feature mode", and
> master will resume its role as master.

We both seem to agree that the numbered "emacs-25" type branches track
the development of each release.

I suggested branches not have modes.  "Master" would always be where the
major testing occurs.  "Next" would be were new, possibly destabilizing
changes could be made.  Numbered branches would always contain the
history associated with that release.

When developers work on feature that are destabilizing, these get merged
into a "next" branch, hopefully when they have initially tested them in
there own local branch.  "Next" would be where integration testing is
done.

When "emacs-25" is considered complete, in the sense that the next
release would be in "emacs-26", The next branch goes though the process
of merging into master for final testing and bug fixes.  When ready it
it branched as the "emacs-26" release.

At worst this is just a relabeling of the current "master" to "next",
and move the "emacs-25" development to master.  But it makes the
mainline development process more linear.

"Master" would be where most of the bug testing is done, so people who want
to help out testing Emacs but are not major developers could go and
help.  General users finding bugs could see there fixes done there.
Being "master" it would be the easiest for people to track and build.

People working on next would be more seasoned developers involved
integrating new features and doing the more complex debugging.

No matter what approach is used, I think the major revision time merge
of "next" and "master", (or currently "emacs-25" into master) needs to
be done carefully.  I just think that what is going on in each branch
should the established, rather than a cycling though modes.

I also think that making the "master" branch less volatile and always
the current test area would help open up the bug fixing to a wider
audience who may have less Git skills.  People who hope to generally
contribute to bug fixing need only clone the Git repo and use that.

Irrespective of what the policy is, I think you will find most people
that check out Emacs build from the master branch.

--
Barry Fishman