On Sat, 24 Apr 2021 at 10:19, D. Hugh Redelmeier <[email protected]> wrote:
> | From: Andrew Cagney <[email protected]> > > | Around the 4.5 release I'd like to put forward making a few pervasive > | changes. > > I don't know all the logisticsl > > | When I say around I mean that period around the release during which the > | mainline is pretty much frozen. > > Makes sense. > > | before: > | - s/TRUE/true/ s/FALSE/false/ > | If this is done just before the release patches to 4.5 won't have to > deal > | with it. > > Yes! > > If a tool will handle it, be a little more careful: > > s/\<TRUE\>/true/g > s/\<FALSE\>/false/g > > GNU sed seems to handle this: > > $ echo 'x x xx' | sed -e 's/\<x\>/y/g' > y y xx > > Yes, it isn't trivial. For instance, TRUE and FALSE embedded in strings and comments probably shouldn't be touched. The hack I tried anchored things a little by using ' = TRUE;' for instance. > | after: > | - add ikev1 to all the ikev1 test names; and ikev2 to all the ikev2 > | test names > > (Broken Record) "ikev1_" is too long. We should systematically use > "v1_" or something else concise. For test names, "1_" should be OK. > > When can we ditch ikev1 code and make this moot? I thought we'd long > passed our original target. > I consider the test names to be public facing. Hence, I don't think using ambiguous abbreviations is useful. Besides being able to glob *ikev1* is going to be far more robust than globbing *1_*. Oh, my money is on ikev3 arriving before we eliminate ikev1 :-) _______________________________________________ > Swan-dev mailing list > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan-dev >
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
