This is the mail archive of the
mailing list for the binutils project.
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.
> 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
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
> 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
> 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.
> On Fri, Apr 27, 2012 at 9:05 AM, Tristan Gingold <firstname.lastname@example.org> 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-188.8.131.52.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.