This is the mail archive of the 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!


> The instructions to do it (as given by the previous release manager) is 3 pages long.
> About half a day.
> All these steps are automated by a script. ?At each release I update and improve the script (and that also takes time).

These seem to be contradictory. If the steps are performed by the
script, then it's a key stroke worth of work. If not, then they're not
*really* performed by the scripts. mvn release:prepare <enter version
numbers> <have coffee> mvn release:perform <have tea and biscuits>
done. 2 hours max for a big build with a stack of unit tests and code
metrics, static analysis, etc. Human interaction: 5 minutes.

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

Right, because the 2.22.1 etc releases really should have gone out as
the (key) fixes went in.

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

It shouldn't  be about what you want. It should be about a bug being
important, or not, and if one is important, then it should dictate a
minor release.

> I am not sure that SCM tool is an issue here.

Maybe not, but maybe :-)

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

I might be misunderstanding and way off track, but that reads like
"Someone else downstream will fix it if we put it out broken, so why
bother, let them do it.". I hope that I'm very wrong. By second
release process, you mean "select binutils base, apply patches until
happy, release as -dfsg-1 etc", right? It's got to be better for
everyone to bother from an end user point of view. The tools will be
more consistent distro to distro if they're patched less before final



> Tristan.
>> Regards,
>> Fred.
>> On Fri, Apr 27, 2012 at 9:05 AM, Tristan Gingold <> 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-
>>> 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]