[Swan-dev] are waiting for f28 or for big changes?

[Andrew Cagney]

On Mon, 16 Jul 2018 at 11:33, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
>
> | From: Paul Wouters <paul at nohats.ca>
> |
> | I want to start merging in some code that will cause some test failures
> | to fixup. So are we waiting to move to f28 before those, or are we doing
> | these first now because the tree is already heavilly modified since
> | 3.25?
>
> I don't understand.  I try to commit test fixes at the same time as
> the code changes that prompt them.  You've said that you don't want
> them in the same commit, but they can be in adjacent commits, pushed
> at the same time.

I've been trying to avoid changes that badly churn the test output.
Our results are still pretty good (and I think I've figured out a fix
to the name=(null) bug which will fix an apparent bit rot).

However, I might have reached in-pass as my next changes to the algorithm list:

- sort it - they are currently ordered by the host dependent SADB ID!
- update the listed names/values - use ike_alg values

>From experience I know these never go to plan :-(   It might even be
easier to strip out most of the cases where the kernel algorithms are
being listed - not material to the unit under test.

> Really trivial example of a pervasive change: standardizing on
> TRUE/FALSE or true/false.  We've got a lot of each and that's
> annoying.  Fixing it can make merging more difficult.  I tried to
> discuss this on the list but we didn't get consensus.  So it's not
> ready for implementation.

But a change like this - updating our code so that it is consistent
that part of the kernel coding standard - shouldn't churn the test
results.

Andrew