On Thu, Jun 17, 2010 at 4:13 PM, Russ Allbery <[email protected]> wrote: > Stephan Wiesand <[email protected]> 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 thought that enabling DAFS to be on by default was the major feature of 1.6. 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. Steven _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
