[OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Russ Allbery rra@stanford.edu
Thu, 17 Jun 2010 12:44:15 -0700

Stephan Wiesand <stephan.wiesand@desy.de> writes:
> On Jun 17, 2010, at 21:01 , Simon Wilkinson wrote:

>> Because every different configuration option you have doubles the
>> complexity of testing the code. What actually tends to happen is that
>> stuff that isn't enabled by default never actually gets tested when
>> changes are made, and so ends up rotting.

> hmm, that would apply to DAFS unless it's enabled by default starting
> with the 1.6 RCs?

Yes, absolutely.  It's one of the reasons why 1.6 has taken so long.
There probably isn't any other sane way to drop in a major, disruptive
change, but certainly the long-term goal is to ensure DAFS works in
production, then make it the default (I expect for 1.10 or 2.0), then
remove the non-DAFS code so that we get back down to one implementation
(almost certainly not before 2.2).

You'll find that in 1.6 we've been trying to pare down our configure
options a lot, and many things that were previously configure options are
now just enabled by default, such as support for bos restricted mode.

> That's completely reasonable. But it clearly means that DAFS should the
> one and only option to run fileservers with 1.6+. Is this what's
> planned? Fine, let's test it (and nothing else) and get it ready. But if
> DAFS remains an option that has to be enabled explicitly at build time,
> I'm with Rainer and Christopher: please leave fast-restart and
> bitmap-later in place.

What I said at the start of this thread may have been lost somewhat over
the course of this discussion:

  At the point at which we make demand attach the default, rather than
  optional behavior, I believe we should remove the code for these two
  flags.  I think that should be for either 1.10 or 2.0 based on
  experience with running 1.6 in production.  In the meantime, please be
  aware that most of the developers don't build with those flags by
  default and the code is not heavily tested.

So there's no need to ask that the code be left in place as long as DAFS
is an option that has to be enabled explicitly; we're not proposing doing
anything differently.  :)

Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>