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!


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

Sure, of course, there are always some small things, but for the time
you're talking, it sounds like there are a lot of them, that's all.

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

But but but, isn't this already handled in the one month stabilisation
period? If not, what exactly *is* going on in that month? Doing the
release, to me, is saying "OK, we all agree, this is ready, passes all
tests (make check, etc), let's bang it out" and then just do it. IE,
tests pass with flying colours because everyone already checked that
during the one month.

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

lol, fair enough!

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

Then why do people want it? Different threshold for "important" ?

> Very few people are using binutils directly from the release.

Of course, but they, presumably, all *base* their releases off of some
upstream release, and patch from that, even if heavily. So, then, the
quality of the binutils release directly impacts the amount of
patching required.

My latest apt-get update says that I'll get 2.22-6 if I upgrade, which
is 6 deb releases based on 2.22 with patches. Looks to be based on the
last release to me. The one currently installed is dated July 7 2011
and has version which a quick ddg search reveals is
from HJ Lu. Wow. Alan's right, the entire team should be able to put
out something more attractive than one man, you'd hope. In any case,
both are based on released versions, be they official or otherwise.
Red hat appear to be using the HJ Lu stuff as a base too, from what I
can tell, though up to date info isn't easy to find.

It would appear that the ecosystem is happy because HJ Lu is doing
lots of regular small releases off of presumably well chosen base
points. I guess it's a good sign for the core development that Deb
switched back to the official release for a base. Perhaps others will
follow suit?

> Sure, but that's outside of our power.

Mostly. The only way to influence that is to ensure high quality and
regular output.

I hope some of the key stake holders speak up with their more detailed
thoughts on all of this.



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