As its a change to a default, I would object to the change. Especially w the potential code issues and potential inability to go back to supergroups off. Changing the default is not a bug fix or security fix.
Such a change should either be reflected in a major version number change such as 1.8 or have a second set of packages, say 1.6.2-sg. IMHO. Sent from my ASUS Pad Jason Edgecombe <ja...@rampaginggeek.com> wrote: >On 12/28/2012 03:33 PM, Simon Wilkinson wrote: >> On 28 Dec 2012, at 19:20, Andrew Deason wrote: >>> I'm not sure if that's really an absolute requirement, though. The 'code >>> quality issues' that I remember were just the opinions of a few people >>> that would make them uneasy about turning it on. I don't recall anyone >>> trying very hard to get the default changed, so maybe that's all it >>> takes. >> There were/are a number of different issues in the supergroups code. There >> are aliasing issues throughout, some of which could be easily fixed by >> inserting memcpy's rather than just using casts/assignments, but there are >> others that require far more in depth analysis. This second set of aliasing >> problems are mainly confined to the caching code, rather than the >> supergroups code itself. It would certainly be possible to either disable >> caching, or rework that code, whilst having the ubik database format remain >> unchanged. >> >> The other major issue is that there is bit twiddling in the caching code >> which makes assumptions about endianness, and about word size. I think we >> have now caught all of these problems - but certainly with the 1.4 series >> you couldn't safely run supergroups on a 64 bit machine. >> >That's slightly unsettling. We're running supergroups-enabled cell >servers on 64bit RHEL5, albeit with YFS modifications. > >My main desire is to reduce the number of conditional features to reduce >code rot and extra ongoing development/testing efforts. > >Jason >_______________________________________________ >OpenAFS-devel mailing list >OpenAFS-devel@openafs.org >https://lists.openafs.org/mailman/listinfo/openafs-devel >
