Re: 2.22.1 Possible -> Yes!

[Fred Cooke <fred dot cooke at gmail dot com>]

3 days to make a release :-o or 3 days for 3 hours each evening? How
cheap is the minor patch release cycle? Ever done a Maven2/3 release?
It's a nice model with testing and source control checks before hand
(release will not work if these don't pass), automatic numbering,
building, tagging, uploading, documentation build, docs upload, etc.
Once configured, which isn't difficult, a release like this just takes
the time the machine takes to execute it. The work is only in
preparing the source for that point. Clearly binutils is a more
complex beast, but it's a nice goal to aim for.

Minor branches like 2.22 should only exist for the purpose of applying
(and releasing) fixes deemed important enough to apply. It doesn't
make sense to create it in the first place unless there is an issue to
fix. Tag for release, branch on issue found. Point being, it shouldn't
exist in a stagnant way. If a genuine issue is found and can be fixed
fairly promptly, then the minor release for it should go out ASAP. It
shouldn't just be applied and forgotten about, that's pointless and a
waste of energy.

If, post release, a lot of changes are going into both release branch
and trunk then to me it screams "trunk wasn't ready for release".
There are (at least) two choices here, then.

1) have a stabilisation period in which no big changes occur, and only
well-tested peer-reviewed fixes go into trunk and release when fairly
stable
2) branch the release early prior to release, apply only well-tested
peer-reviewed fixes to the about-to-be released branch, and all
changes, fixes and features to the trunk.

1 means that you hold up and slow down dev on trunk
2 means that you have the large overhead of splitting/merging
fixes/features much like Alan's complaint about the post release
branch

Even once the Git migration is complete 2 or "released too early" are
still a hassle. Likely orders of magnitude less of a hassle, though
(keep saying CVS is fine... lol).

I guess that the real trouble is in the wildly different rates of
change on different architectures. It'd be easy to say "release now"
for any given one, but near impossible to do it well for all of them
at once. Therefore obviously core stuff like x86, amd64, arm etc
should really be held important for that process.

I might have said "solution = keep trunk more stable" but I've seen
the submit/approve process that patches go through here, and it's
already pretty good, so it's unlikely to be easy to improve upon.

Regards,

Fred.

On Fri, Apr 27, 2012 at 9:05 AM, Tristan Gingold <gingold@adacore.com> wrote:
>
> On Apr 27, 2012, at 5:41 AM, Alan Modra wrote:
>
>> On Thu, Apr 26, 2012 at 10:07:27PM -0400, Mike Frysinger wrote:
>>> a release from trunk means 2.23, not another 2.22.
>>
>> What matters the number?
>
> Well, there are guidelines and expectations.
> That's a detail anyway.
>
>>> i also don't think you can
>>> say that the trunk is that much better considering it hasn't been released and
>>> tested on distros for a variety of targets.
>>
>> I do claim that. ?I can claim that based on the number of bugs I know
>> have been fixed on trunk but not on the branch. ?I also know that
>> people use trunk binutils in production, and HJ releases binutils
>> effectively off trunk all the time, so it's not as if trunk is only
>> tested by developers. ?Even distros use trunk snapshots as their base
>> for binutils, eg. RHEL6.3 is based on binutils-2.20.51.0.2.
>
> Like many others, I agree with you. ?There are some instabilities periods, but they are rare and short.
>
>>> if trunk really truly was as well
>>> tested & stable as you say, then we wouldn't have releases which were badly
>>> broken for some targets. ?this isn't anything specific to the 2.22 branch
>>> point, just a reality of development -- bugs slip through. ?every release has
>>> its own set of issues.
>>
>> Long release cycles tend to break less used targets. ?I think my
>> suggestion will allow shorter release cycles, simply because the
>> release process will not impact developer time so much.
>
> If you want to talk about release cycle, I think this deserve a real thread and maybe a live discussion (at Prague ?)
> My current schedule is one major release every year.
>
> Tristan.