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

Steven Jenkins steven.jenkins@gmail.com
Thu, 17 Jun 2010 16:22:19 -0400

On Thu, Jun 17, 2010 at 4:13 PM, Russ Allbery <rra@stanford.edu> wrote:
> Stephan Wiesand <stephan.wiesand@desy.de> writes:
>> On Jun 17, 2010, at 21:44 , Russ Allbery wrote:
>>> Yes, absolutely. =A0It'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. =A0:)

I thought that enabling DAFS to be on by default was the major feature of 1=

I do not quite see the point of moving the release numbering from 1.5
to 1.6 if DAFS is not enabled by default.