libtool
[Top][All Lists]
Advanced

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

Re: libtool-2.0 release


From: Gary V. Vaughan
Subject: Re: libtool-2.0 release
Date: Fri, 03 Feb 2006 12:06:40 +0000
User-agent: Thunderbird 1.5 (X11/20051201)

Ralf Wildenhues wrote:
> Hi Gary,

Hallo Ralf!

> Gary V. Vaughan writes:
>> Now is the time to branch!  Either a feature branch for developing the
>> per-deplib feature for merging after 2.0, or else a 2.0 branch that we
>> can keep stable.
> 
> No way, without me.  I outright refuse to maintain another branch.
> It's insane.  It makes more work for us and causes the resulting code
> to receive less outside testers per branch.

Agreed.  My aim is to not churn the code that will be released any more
than necessary, and I suggested branching to give you somewhere to commit
your patch without the code churn... since you're happy to maintain your
patch outside of CVS for a while, I concur that branching is way more
work than necessary.

> However, I have absolutely no problem with delaying the application of
> the per-deplibs-flags patch to shortly after 2.0.0 or 2.0.2.  Although
> we should still commit both the `-static' hardcoding fix and the
> static.at test patch (the latter is written so that it works also
> without the per-deplibs-flags patch; it needs only -static-libtool-libs).

Agreed.  The more tests we commit, the better.  I think adding tests that
will fail due to known bugs in the release is okay too... we just mark
them XFAIL until the known bug is fixed after the release.

>> According to: http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap, the
>> three remaining release blockers for 2.0 are:
> 
> The list is outdated.

Bummer :-(

>>  * <!> libtool.m4 macro ordering/requirement audit. pending
> 
> This is as good as done.  Forget about it.  I have a list of remaining
> issues (not with me right now), and I will get to it eventually, but am
> pretty sure those issues are not important to many users.

Okay, moved to 'fixed'.

>>  * <!> LT_WITH_LTDL should build libltdl by default; currently
>>        nothing happens unless LTDL_CONVENIENCE or LTDL_INSTALLABLE
>>        is also given.
> 
> I don't even know what this means.  I'd guess we should ignore it?

It means that LT_WITH_LTDL in configure.ac that mentions neither
LTDL_CONVENIENCE nor LTDL_INSTALLABLE doesn't build libltdl at all.
I have a start to a fix for this.

>>  * <!> fix potential denial of service with compilers that do not
>>        understand "-c -o".
>>        * not very likely to happen
> 
> I don't mind postponing that to after 2.0, iff that is _not_ responsible
> for bugs like this one: http://bugs.debian.org/350989 .  I have replied
> there, BTW.

Okay.  I'll leave it on the list as is until you determine whether to
postpone or not.

> HOWEVER.
> 
> - The regressions that happened in 1.5.22 need to be fixed in 2.0,

Agreed.

>   IMHO (most notably the OpenBSD failure; and good would be the
>   application of the `-static-libtool-libs' patch for users that
>   need the other `-static' semantics; together with the hardlinking
>   regression that I also found for `-static')

I agree that fixing regressions is necessary.  I'm not sure that we
need to delay the release for new features...  Can you amend the RoadMap
to reflect your thinking on this please?
.
> - And my outstanding patch-6 needs to be split up and applied.
>   It fixes most but not all remaining issues with HEAD libtoolize.

Agreed.

> - I know about a couple more tweaks necessary for HEAD libtoolize
>   and Bob has a couple of failures I (or somebody else) need to track
>   down.

Agreed.  If you put them on the RoadMap, I might get to them before you.

> - AC_PROG_SED may not be AC_DEFUNed (for aclocal < 1.6?), and
>   LT_AC_PROG_SED should be catered for.

D'oh!  I have a patch for this already :-/  I'll post it presently.

> - Makefile.am rules somewhere use GNU make 3.80 features.  I have
>   encountered many difficulties preventing autotools reruns on other
>   systems, and am quite fed up with hunting these down.

:-(  I haven't tripped over those yet.

> - I have a pending Solaris/whole_archive_flag_spec patch, fixing a
>   regression, and to make libtool work on Solaris 10.

Cool!  Please add an entry to the RoadMap.

>> So here are the action points, initialed where I plan to take them
>> pending agreement from (most of) you guys.
>>
>>  1. strike the macro ordering audit from the release blocker list.   GVV

Done.

>>  2. fix LTDL_{CONVENIENCE,INSTALLABLE} bug on CVS HEAD.              GVV
> 
> OK.  Whatever that may be.  You webpage does not seem accessible at the
> moment.

Yeah, my ISP seems to give me 10 min outages once or twice a week... or else
my new modem takes that long to notice the dropped connection from the
ISP end and redial.  Sorry about that :-(

>>  3. make a per-deblib-branch for these changes.
> 
> Do not make a branch.  Pretty please.

Strongly agreed!

>>  4. evaluate whether -c -o DoS is a release blocker too.
>>     4a. fix it if it is
>>     4b. strike it from the blocker list if it isn't
> 
> See above.  I have a half-baked fix lying around somewhere, but will
> post only after many tests.

Okay.  But please let us know whether you're happy to postpone until
post 2.0 when you can. :-)

>>  5. test like crazy. and fix any platform issues uncovered           GVV
> 
> If I haven't made it clear yet: that is what I've *really* been doing.
> The static test was the aim, and the bulk of the work, the per-deplibs
> flags and the `-static' hardcoding fix were the fallout.

Much appreciated it is too.  I started testing, but became busy, and
noticed the patch rate was still high... I'll start again when we've
nailed the release blockers.

> And I have several more tests which I would like to write or have
> already started.  For example: I would like comprehensive exposure of -L
> path issues in order to fix the OpenBSD link `-L path order issue' right,
> so that it does not turn into another regression on another system.

Okay.  Adding tests at any time is fine by me.

> I know you would rather release.  There is a trade off: better test
> exposure vs. release delay.  My being fed up with working on bootstrap
> and similar issues that were mostly introduced by the great code
> reorganizations, and also there being very few test suite contributors
> and people working on bug reports, has led me to work on the former.

NP.  However, there is plenty to be said for letting the community
tackle some of the testing.  Although we need to show diligence and not
release with gaping bugs, a mostly good 2.0.0 release will provoke a
huge amount of feedback and testing that we can funnel into a speedy
2.0.2.  I'd hate for you to burn yourself out looking for corner cases,
especially when much of that work will be done by the community post-
release anyway.

> Libtool will only get consistently better with a testsuite that exposes
> much more issues.  And if you then keep to adding features only with
> comprehensive test exposure already (which static.at probably isn't for
> the patch at stake here), then adding features to libtool won't
> destabilize it much.

ACK.  I think we can be justifiably proud of the huge improvements we've
brought to the new testsuite in the last 18 months.

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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