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

[D. Hugh Redelmeier]

| 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'm guessing that you are thinking about the problem of maintaining
pervasive changes, including changes to the tests, on a branch.  The
longer one has to do this, the more useless maintenance one has to do.

We need a process for scheduling these pervasive changes.  We all know
that.  The process is: Paul schedules, in consultation, with wisdom
and understanding.

This isn't going too well.  Witness how our release freezes (an
analogous thing) are just too long and painful.  The reverberations
of the last one have perhaps died down now.

Let's be explicit.  These large/pervasive changes:

- should be deployed quickly (e.g. a freeze should be for a period of
  perhaps a day or two)

- they should be sequenced (one at a time (duh!))

- they should be batched (if there are three large changes ready to be done, they
  should be done during one lockdown).  This is a win because it
  avoids multiple periods of warning.  But this should not be an
  excuse to make the freeze to last too long.

- all should be scheduled accurately and that schedule
  announced/negotiated sufficiently ahead of time for everyone to be
  ready.  But within reason: in some sense the disruption time
  includes the lead time since we programmers need to wind down our
  own work.

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.