[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC+PATCHES] Refactoring `tests/defs.in'.
From: |
Ralf Wildenhues |
Subject: |
Re: [RFC+PATCHES] Refactoring `tests/defs.in'. |
Date: |
Thu, 2 Sep 2010 19:22:11 +0200 |
User-agent: |
Mutt/1.5.20 (2010-04-22) |
Hi Stefano,
* Stefano Lattarini wrote on Wed, Sep 01, 2010 at 11:35:47PM CEST:
> I think it's about time to start the refactoring of `tests/defs.in'
> we spoke about many times in the past.
>
> I'd like to do this in small steps, posting one or two patches at the
> time and waiting to have them reviewed/approved before posting the
> following ones (thus avoding a "diff-bomb" of a patch series with
> twenty patches or more).
OK sounds good.
> I moreover think that this refactoring should be done in *two* public
> branches (e.g. "sl-tests-init-refactor-maint", stemmed from maint, and
> "sl-tests-init-refactor-master", stemmed from master). This is
> required becase:
> 1. `test/defs.in' in master differs from `test/defs.in' in maint,
> so that a refactoring step which is complete in maint might be
> incomplete in master;
> 2. some changes to `tests/defs.in' will entail related changes to
> various test scripts, and some of these test scripts might be in
> master only.
If it is problematic to share code between master and maint, then we
should just go for master. I don't expect branch-1.11 to see a lot more
updates, a point release or two maybe. Let's avoid doing double work.
I'm fine if you just name the branch refactor-defs or tests-init or so.
The name prefix is not really needed with the big number of branches we
have at the moment. ;-)
> In the meantime, I have prepared and attached a couple of (mostly
> cosmetic) patches extracted from my old private branch.
1/2 is ok, thanks. I actually find that some of the extra spacing
removed in 2/2 makes the code a bit more readable. I don't have a
strong opinion on norming the spacing; another reason the code is
not very consistent wrt. spacing around parentheses is that in some
situations spaces are required, e.g., ((subsubshell)) is wrong, as
would be {oops;}. This is probably why it's inconsistent throughout
the code. I don't think that is a big problem though.
Cheers,
Ralf