emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Move to a cadence release model?


From: Eli Zaretskii
Subject: Re: Move to a cadence release model?
Date: Wed, 11 Nov 2015 17:49:27 +0200

> From: John Wiegley <address@hidden>
> Date: Tue, 10 Nov 2015 15:58:20 -0800
> Cc: John Yates <address@hidden>, address@hidden,
>       Emacs-devel <address@hidden>
> 
> I would indeed like to see several .x releases within a cycle, fairly evenly
> spaced. x.y releases would wait until we have a larger set of features ready.

We more or less do this already, so no significant change there.
Releases from emacs-24 branch were done approximately every 6 months.
The intervals could be made shorter if we don't allow new features on
the release branch.

> Doing this properly may mean dividing how we develop Emacs, though, with
> active development on both the "current release branch (25.x)", and the "next
> major release (26.1)". Merges would proceed daily from the former to the
> latter, but rarely in the other direction (and only by cherry-picking).

Careful here: you are talking about maintaining more than 2 active
branches.  We still have veteran developers who regularly shoot
themselves in the foot with even 2 branches, and others who evidently
cannot safely work on a feature branch without messing up their DAG.
Last, but not least, gitmerge.el is still very much in diapers, and
doesn't support more than 2 branches.

Most places I know about have separate teams working on each branch.
Do we have enough people to do that?

> We want an active focus on bugs -- toward a stabler .x -- but we don't want to
> inhibit integration of feature branches toward the next x.y as they become
> ready.

As I wrote earlier, "active focus on bugs" is a pipe dream as long as
the number of people who care about bugs enough to pick them up,
investigate, and work with the submitters or by themselves to debug
them is some prime number less than 3.  We will never succeed in
moving forward to some more elaborate development model if we don't
have this issue covered much better than we do now.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]