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!


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

Regards,

Fred.

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