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!

On Apr 27, 2012, at 2:40 PM, Fred Cooke wrote:

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

Sorry, most of these steps.

Some are not: for example I need to create a new version entry in Bugzilla, and the only way I know for doing that is the web interface.

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

There are always failures to address; I also analyze the results of 'make check' which is never clean, ...

>>> 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 disagree about this release policy (or if you want to read it another way, I don't have enough time for it in anycase).

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

In the case of the 2.22, I think there isn't any important bug up to now.

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

Yes, you are very wrong.
Very few people are using binutils directly from the release.

Packagers have other criteria and testsuite for their binutils release.  For example, I suppose RH wants to be able to build all its packages with their version of binutils and if they found a bug, they will fix it.

I only run the binutils testsuite for many targets on a few hosts.

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

Sure, but that's outside of our power.


> Regards,
> Fred.
>> 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]