libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]


From: Peter Rosin
Subject: Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
Date: Tue, 08 Jun 2010 10:22:24 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4

Hi Gary!

Den 2010-06-08 09:34 skrev Gary V. Vaughan:
[[Adding Libtool List]]

On 8 Jun 2010, at 08:42, Charles Wilson wrote:
Which is why I don't think even the Peter's long-ready MSVC patches, nor
my pile of pending patches, are candidates for this extremely shortened
release cycle.

Regarding these patches, I honestly have paid very little attention to
Windows fixes for libtool because I can't test them, and don't use them:
So I figured someone else was taking care of it.  Since that obviously
isn't the case, and because I'd hate to see them bitrotting indefinitely
in the list archives, we can either commit them on the trunk after 2.2.10,
or else create a topic branch in git to collect them together for testing
and merging back at an appropriate point.

There's already the pr-msvc-support branch, but when I tried to merge
master into it to make it easy to merge back later, the ChangeLog rotation
caused conflicts. How should I resolve those conflicts? By adding the
entries to ChangeLog.2009 or to ChangeLog? I think the "rule" is to
commit with the date preserved even if that causes the ChangeLog to
be unordered, but I don't know how that "rule" applies in the face
of a ChangeLog rotation (or two)...

It seems odd both to (a) have entries from 2009 in the (future-to-be) 2010
ChangeLog and (b) to make changes to the 2009 ChangeLog at this point.

I see that for the first merge of master into the branch last year I
updated the dates in the ChangeLog so that they said 2009, but that's
lying. Sort-of anyway...

Please advice.

Cheers,
Peter



reply via email to

[Prev in Thread] Current Thread [Next in Thread]