This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 2.22.1 Possible -> Yes!


On Apr 27, 2012, at 11:30 AM, Fred Cooke wrote:

> 3 days to make a release :-o or 3 days for 3 hours each evening?

Maybe not 3 * 8 hours, but it is still time consuming.

The instructions to do it (as given by the previous release manager) is 3 pages long.

> How
> cheap is the minor patch release cycle?

About half a day.

> Ever done a Maven2/3 release?

Never used this tool, so I can't say.

> 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.

All these steps are automated by a script.  At each release I update and improve the script (and that also takes time).

> 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.

In the process of a major release, we create a branch, so the release branch will always be present.

> Tag for release, branch on issue found. Point being, it shouldn't
> exist in a stagnant way.

This is exactly the issue of the 2.22 branch: almost stagnant.

> 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.

I don't want to create many minor releases.  And there are major bugs and minor bugs.

> 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.

Basically, we follow 2).  There is a stabilization period of about 1 month.

> 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 am not sure that SCM tool is an issue here.

> 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.

One more work about binutils release:  I think it is not as important as it was in the past.  Many (> 99% maybe) of binutils users use Fedora/Suse/RH/XXX versions of binutils, which follow a second release process.

Tristan.

> 
> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]