-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Simon,
Simon Wilkinson wrote: > > > Your analogy is flawed. No matter how many notes Mozart used, it was > still possible to determine the quality of the resulting work. This is rather neat, but in the conceit, he used too many for one person's taste, in a specific work. > > To be clear, I'm not attacking the addition of new features - I'm all in > favour of them! What I'm against is the addition of code _particularly > on the stable branch_ which is hidden behind arcane combinations of > build time configuration switches. (Run time configuration switches are > a slightly different matter). But the configuration switch issue is > really just a symptom of why this patch is flawed, rather than the cause. Ok. > >> OpenAFS gatekeepers don't need to test all the features the product can >> theoretically perform, they only need to test the ones that are >> _officially supported_. To argue otherwise is, respectfully, some type >> of overreaching. > > Ok. So there's a major philosophical argument here. Why would OpenAFS > ship code that it doesn't support? If the code isn't supported at all, > doesn't it belong in some kind of 'contrib' area, rather than in the > main build. I think there's an assumption that everything in the OpenAFS > tarball is supported, as much as any of OpenAFS is supported. As far as > I'm aware, we're not currently listing a set of options that gives you a > supported build, and declaring 'here be dragons' for everything else. > However this is really beside the point - the patch isn't flawed because > it adds yet-another-configuration switch, but because it does so without > regards for the consequences of making this option configurable. I agree, this is actually an important discussion to have at greater length, in some context. I think we should, perhaps, effectively be doing the supported/unsupported thing. I think there's room for and precedent for there being things we support more, and support less, without external patching. Because drawing the line is hard, I was probably special pleading myself. I agree this is quite distinct from the merits, or lack, of the specific feature. > > My argument, as I've made before, is that the solution presented by the > patch we're currently discussing is neither sensible, flexible nor the > best available. Yes, sorry, I was trying to refer to the "we must test all combinations reasoning" not the ACL bits feature. > > *) A user with a presence in multiple sites has to remember what each > site local bit means in each site. Forgetting this meaning may lead to > them setting permissions on their files which they didn't intend. > *) Systems staff building OpenAFS across a large environment must ensure > that every fileserver build has the same set of configuration options. A > failure to do so means that ACLs will silently change meaning when a > volume is moved between servers > *) Systems staff upgrading OpenAFS must ensure that the new build is > done with the same options as the last one. Failing to do so will cause > ACLs to silently change meaning upon upgrade. > > In my opinion, an acceptable patch would have to address these 3 issues. > I think it could do so by adding a mapping RPC, similar to what Derrick > has already discussed to solve the first issue, and by having the > ability to detect, and warn of, the latter 2 cases. Issue 1 indeed seems intrinsic to dealing with the ACL bits feature. Issues 2 and 3 seem--very different? Again, let's say that the way we ensure the correct set of build options is used by suggesting that users deploy OpenAFS-provided builds where possible, and suggest detailed guidelines for site administrators and external port maintainers, where it isn't. Of course, I suppose we actually could introduce mechanisms which warn of inconsistent configuration of programs deployed in the cell--is that something you were suggesting? > I think your experience of the world has been a little more cosy than > mine. I can think of many sites that don't coordinate releases in this > way. They probably should, but they don't, and that's the world in which > we have to operate. I was being hyperbolic, but, I think I actually meant what I said. Site administrators, &c, need to be responsible for coordinating releases, particularly if they're going to build the product from source. I know very well that the world works differently, it certainly does at my site, I run OpenAFS 1.3.80. But I'm not sure how much weight to give the obligation to prevent foot shooting, in general, there are a lot of things we can be doing besides reducing conditional build options to reduce its incidence. > > S. > _______________________________________________ > OpenAFS-devel mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-devel - -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJPrvQJiSUUSaRdSURCC8DAJ0X4Lrz57L6y9jc/stE6y4WRDsu6QCfRh4o kmWtKNijDsURK9qFwTdJdmc= =ftFZ -----END PGP SIGNATURE----- _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
