On 02/01/2012 10:40 AM, Peter Rosin wrote:
> Stefano Lattarini skrev 2012-01-31 22:23:
>> On 01/31/2012 09:30 PM, Peter Rosin wrote:
>>> Stefano Lattarini skrev 2012-01-31 14:31:
>>>> On 01/31/2012 01:55 PM, Peter Rosin wrote:
>>>> (I know, the present organization of branches sucks in some respects;
>>>> we might rethink it after the 1.11.3 release, OK?)
>>>
>>> I would love to send maint, msvc and branch-1.11 to some dump
>>> somewhere far away with a one-way ticket.
>>>
>> Oh no! maint and branch-1.11 are were we cut the 1.11.x releases from,
>> so until 1.12 is out, they are here to stay. Sorry.
>
> Of course, that was just my way of saying that I'd like 1.12 to already
> be out...
>
Eh :-)
Maybe it's time we start thinking about releasing 1.12 ...
> [SNIP] various good objections and explanations ...
> I suspect that most aren't as hindered by this state of affairs as
> I am, as maint is just broken for me. I have to merge maint into
> branch-1.11 and test changes there instead. Not a big deal if you
> have to do it once or twice, but it gets cumbersome. And it's
> confusing.
>
> On the "drop maint" line of discussion, I don't think that's a wise
> move. If you drop maint - and release directly from branch-1.11 -
> you'd "leak" e.g. the version change in configure.ac into master the
> next time you merge branch-1.11 into master,
>
Nope: I would just get a one-line merge conflict, very easy to solve
(just keep the version from master, and you're done -- difficult to
mess this up). Much better than the present situation IMHO.
> and you don't want
> that. So, instead you'd create a release branch off of branch-1.11
> and do the version change there, but then you'd want to base the
> next release off of the old release. And by then you are back to
> square one with the future branch-1.11 being the equivalent of the
> current maint.
>
See above.
> I think the rule should be that maint should be kept *very* close
> to branch-1.11 (only differing by release related commits such as the
> above example with the version in configure.ac). This isn't true
> today (e.g. msvc is merged into branch-1.11).
>
Keeping maint and branch-1.11 very close was the plan initially, but we
(and I think it was you who pressed for this ;-) decided that the MSVC
stuff was better to be published in the 1.11.x line (although disabled
by default), rather than left as "vaporware" in master only. I still
think that was a good decision, all in all.
>>> They have simply diverged too much. At least for me, I'm only somewhat up
>>> to speed on the ar-lib mess, but you might be in a different position having
>>> written most (all?) of the other diverging changes.
>>>
> [BIG SNIP]
>
> Oh f/\(|<, I did a "full check" on branch-1.11.
>
> If I run with AR="/home/peda/automake/lib/ar-lib lib" in the environment
> PASS: extradep (but uses ar as the archiver)
> PASS: extradep2 (libtool AC_SUBSTs AR, not needing AM_PROG_AR to do that)
>
> If I also move ar out of the way (why would I need it when AR is pointing
> elsewhere?)
> FAIL: extradep (ar is not present)
> PASS: extradep2
>
> If I run with AR=lib in the environment
> PASS: extradep (but uses ar as the archiver)
> FAIL: extradep2 ("lib cru" doesn't work)
>
> If I also move ar out of the way (why would I need it when AR is pointing
> elsewhere?)
> FAIL: extradep (ar is not present)
> FAIL: extradep2 ("lib cru" doesn't work)
>
> No AR in the environment and ar moved out of the way
> FAIL: extradep (ar is not present)
> FAIL: extradep2 (ar is not present)
>
> With the patch, all 10 cases above PASS and ar is never used even if
> present. So, I'd say we are mainly in your second point making the
> tests runnable with MS lib and thus fixing testsuite bugs.
>
Thanks for the detailed analysis ...
> I pushed the patch to branch-1.11 with this updated commit message:
>
> tests: add AM_PROG_AR to help losing archivers
>
> Without AM_PROG_AR, using Microsoft lib as the archiver causes
> testsuite failures.
>
> * tests/extradep.test (configure.in): Add AM_PROG_AR.
> * tests/extradep2.test (configure.in): Likewise.
>
... and for the improved commit message.
Best Regards,
Stefano
