Re: tests updates

[Ralf Wildenhues]

* Stefano Lattarini wrote on Wed, Nov 03, 2010 at 02:27:47PM CET:
> On Monday 01 November 2010, Ralf Wildenhues wrote:
> > I'm so totally behind on patches and not getting better, that the
> > strategy of ignoring testsuite work will not help either.  So how about
> > the following.  IIRC you suggested a branch for low-danger testsuite
> > updates.  I'm not sure if a single branch would always be the right
> > thing to do, often things that are independent can better be treated
> > in independent branches.  But anyway, how about if you go ahead with
> > the idea of merging such patches, preferably based off of maint and
> > merge to master (unless there are really good reasons why branch-1.11
> > would need them too), with the following strategy similar to Libtool:
> > you post the patches, and push them after 72 hours if no feedback by
> > then.  WDYT?  Does that sound good enough for you?
> Definitely yes, thanks!

Good.  I wouldn't want to lose your work just over my lack of time.

> Just one question: what about the already-existing "tests-init" branch?
> Should I try to bring it to a point where it can be easily merged into
> master, and then forget about it, or should it continue to live parallel
> to master?

Right now the branch looks like its changes would be fairly safe to
merge to master, but also, it would mean that sharing testsuite patches
between branch-1.11 and master may become a bit more cumbersome.  So I'd
say it depends a bit on where you want to go with this in the long run.
We can easily move to a strategy of having new testsuite stuff added to
master only by default, and only care about branch-1.11 for fixing
existing regressions and serious bugs, which would probably make the
situation easier.

Of course there are other active branches too, that shouldn't have a
harder-than-necessary time.

We could treat merges similarly to patches in announcing the intention
to merge 72h before the fact, in those cases where there is doubt over
the merge (or the precise point at which a merge should be done).
I must admit that I don't have all that much experience with merges of
longer-term branches done by more than one person; one alternative would
be that you suggest the merge and I do it (if that works out).  Testing
such merges usually requires a bit of additional work, in that both
branches need to be checked for global changes that need adjusting in
the respective other branch.  Let's see how this works out.

Cheers,
Ralf