Re: Release 0.26: branching

[Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>]

On 16/11/15 23:57, Mike Frysinger wrote:
> On 16 Nov 2015 12:14, Tristan Gingold wrote:
>>> On 14 Nov 2015, at 02:29, Mike Frysinger wrote:
>>> i wouldn't mind every 6 months myself.  then release slippage isn't as big a
>>> deal.  i think the fact that there is only one release a yes is what pushes
>>> people to try and get their feature in, even if the quality is subpar.  if
>>> they don't, then it'll be over a year before users see the results.
>>
>> I fear the problem would simply happen twice per year :-(
>> We already have two releases per year: a major and a minor.
>> Do you suggest having 4 releases per year, or only two major ones ?
> 
> we should release when it makes sense.  at least 2 major ones, and do
> minor releases when there are fixes available we want to push out.
> 
> it seems to me that the friction for cutting releases is fairly high.
> maybe we need to polish that so cutting releases isn't onerous ?
> -mike
> 

I agree that two major releases a year would be a good idea.

Over the past few years ARM has been in the unfortunate situation where
the binutils release branch is being cut (or at least scheduled to be
cut) at almost exactly the same time as the first public announcements
of new products.  Note that we have no control over the timing of such
announcements :-(

Since we couldn't publish support for these features until after the
public announcements have been made we've been left in the uncomfortable
position that we didn't want to wait a full year before binutils
supported the new features, but avoiding that meant pushing for changes
to be incorporated into the release process and thereby disrupting it.
I accept that this is undesirable.

(I would point out at this point that, unlike in the compiler where it
is often sufficient to simply recognize a new product name initially and
then progressively enhance support for it over time, binutils support is
often an all-or-nothing situation - you don't really have any support
for the new product until you can handle all the new functionality that
entails.)

If we had two releases per year then the pressure to get support in
immediately would, I think, be significantly reduced.  I think that can
only help to improve overall quality by ensuring that patches have
sufficient time to bake properly on trunk before a release is cut.

My suggestion would be to run a lighter weight version of the GCC
development process (which I think works very well overall) with perhaps
a 5-month development window followed by a one month stabilization
window.  At the end of that month the release branch is cut and a
release made from it once the code is suitably validated.  Backporting
to the branch should be much more tightly controlled than it is at
present to ensure that the release process is pretty quick and painless;
given the higher frequency of releases the pressure to backport new
features can be much more readily resisted -- there'll be another
release coming along shortly!

R.