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

[Russ Allbery]

Stephan Wiesand <stephan.wiesand@desy.de> writes:
> On Jun 17, 2010, at 21:44 , Russ Allbery wrote:

>> 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).

> sorry, I disagree. If you (the developers and the gatekeepers) are sure
> that DAFS is the way forward, and reasonably close to being ready, 1.6
> and on should not support anything else. Why defer this to 1.10?

I'm pretty sure you can find lots of other people on these lists who can
explain why they don't want to have to run DAFS to upgrade to 1.6.  :)

I think this is the best balance between the need to move forward with the
long-term file server direction and not tying the upgrade path too tightly
together.  It's a big leap between having a feature available in testing
and development releases and having it be mandatory in stable code.  We
don't want to make that leap in a single release; it's too hard for people
to back out temporarily if something goes wrong, and DAFS needs more
widespread production shakeout before we can be sure that we can tell
everyone to switch to it.

> Touch=C3=A9. But I wasn't asking to leave it in place as long as DAFS is
> optional. I was asking to leave it in place until DAFS is the one and
> only option.

That's a reasonable request, although the people who want to keep using
them will probably need to keep testing and fix problems if they break for
the feature to remain working.

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