Hi Russ, On Jun 17, 2010, at 21:44 , Russ Allbery wrote:
> Stephan Wiesand <[email protected]> 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). 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? > 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. :) Touché. 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. Cheers, Stephan -- Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany
smime.p7s
Description: S/MIME cryptographic signature
