On Dec 30, 2012, at 07:41 , Dave B. wrote: > 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.
I agree. Reducing the number of optional features is good, but such a change shouldn't happen in the stable release series - unless there are no doubts that it will just work for everyone, and it doesn't introduce any compatibility issues. Turning on supergroups by default is very unlikely to happen on 1.6.x from my point of view. - Stephan > > 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 -- Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel
