[Top][All Lists]

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

Re: [PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.

From: Stefano Lattarini
Subject: Re: [PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.
Date: Fri, 25 Nov 2011 20:13:18 +0100
User-agent: KMail/1.13.7 (Linux/2.6.30-2-686; KDE/4.6.5; i686; ; )

On Friday 25 November 2011, Gary V wrote:
> On 25 Nov 2011, at 18:59, Stefano Lattarini wrote:
> > On Friday 25 November 2011, Gary V wrote:
> >>
> >> The best reason I can find for keeping the various demo directories
> >> around (despite the fact we already make use of the much better test
> >> harness of Autotest for all our new test cases) from the last time
> >> I wanted to migrate everything out of the legacy testsuite, was that
> >> it exercises the distribution manager's autotools combination on the
> >> testers machine, where the Autotests always use the users autotools.
> >> That's no argument as far as I can see: we want tests to fail as
> >> early as possible on a users machine to help him know things are not
> >> going to work properly if he keeps going - and having the legacy
> >> suite pass is only encouraging users to fight with broken installs.
> >> 
> >> This series of patches migrates all 9 of the demo directory test
> >> groups into Autotest, and allows us to remove most of the legacy
> >> testsuite cruft at the end.
> >> 
> > Just my 2 cents: I'd like to see the test scripts converted one at
> > the time, rather than one group at the time (and assuming that this
> > is feasible), as I found your huge patches basically un-reviewable
> > in their present state.
> The legacy tests are in sets that can't be broken apart without leaving
> the tree in an inconsistent state part way through that set.
Oh.  I thought you could convert them one at the time instead, but they
are inter-dependent, this could become more cumbersome, if not almost
> I could break them up a little more tho', if you think that would help,
> so instead of converting one demo directory all at once, then a final
> patch to clean out the configury cruft... there'd be 9 sets of patches
> each containing almost everything in the current patch, except the
> deletion of the the files in the given test/demo directory, followed by
> a series of tiny patches each adding a dozen lines like this:
> +## ----------- ##
> +## Mdemo conf. ##
> +## ----------- ##
> +
> +AT_SETUP([ltdl load shared and static modules])
> +
> +
> +_LT_CHECK_CONFIG([], [^build_old_libs=yes], [^build_libtool_libs=yes])
> +
> plus removing the equivalent legacy set of 3 *.test files, and then a
> final patch to delete the given test/demo tree, and relevant lines from
> It'll take me a while to go through and do that, and we'll end up with
> 10 large patches each setting up a new tests/ file, about 25
> tiny patches per the above, then 10 small patches each removing one of
> the tests/demo trees, and then the final cruft cleanout patch unchanged.
> If that will make a big difference, let me know and I'll retract these
> patches and post 50 or so to replace them in a week or two when I've
> gone through and broken out the tiny per-test-group sets per the above.
Nah, let's forget about this.  I thought that breaking up your patches
further could be done easily and naturally, but if it is not the case,
I see no real gain in the extra churn.

> >> There's still a few legacy tests
> >> left at the end, which I'll tackle later, but at least maintenance
> >> is a whole lot easier now that we don't need to wait for 9 additional
> >> directories to autoreconf every time we run bootstrap, or distcheck,
> >> or roll up a distribution tarball to test on the local network.
> >> 
> >> This is all in keeping with the theme of most of the patches I've
> >> posted this year, to make libtool easier and more fun to maintain
> >> and contribute to, in the hope of getting more people involved.
> >> 
> >> As usual, subject to feedback, I'll push this whole series in
> >> 72 hours or so.  Make distcheck passes for me on my Mac 10.7 and
> >> my Arch Linux x86_64 machines, but it would be great if folks with
> >> access to other machines could give it a spin to see whether I
> >> broke any of the tests during migration... if you'd like a pre-
> >> rolled distro with my pending patches applied to do that, then
> >> please do ask.
> >> 
> > If you want to send me such a tarball, I might run the testsuite on
> > Solaris 10, Cygwin 1.5.25, NetBSD 5.1 and OpenBSD 4.6 at least.
> Much appreciated.  Tarballs here:
> >  But
> > then you should allow for more than three days for sending feedback
> > -- at least a week.
> That's fine, and running on those arches would be a great help in
> giving me confidence the migration didn't break anything.
> It'll take me at least a week to redo everything into smaller pieces
> anyway... (unless you think the time spent here will not make much
> difference to your review). But do let me know either way :)
Done above :-)  Don't bother in breaking up the series.

> And thanks also for offering to make the time to look them over.
If you meant testing them, that won't require much time from me -- the
machines will do basically all the work ;-)


reply via email to

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