On 6 Dec 2010, at 04:28, Andrew Deason <[email protected]> wrote: > > Features that are backwards-incompatible, and cause nontrivial downtime > to revert, I'd hope we'd wait at least a release.
We could easily structure this change in a way that preserved backwards compatibility. > And keep in mind I'm trying to think of stable release > cycles in terms of what was discussed at BPW 2010, not the glacial pace > of e.g. 1.2 -> 1.4. It wouldn't/shouldn't take that long. We have still to demonstrate that we can rapidly make stable releases. 1.6 is taking an age to get out of the door, primarily due to demand attach. > And rapid changes can get really annoying, too. Have already gotten a > little annoying (Just a little! :) As we haven't done any stable releases with major changes recently, I can only assume that you are referring to the rate of change on master. In this area, I have little sympathy - there's pretty clear evidence that we need to innovate or die, and major user demand for new features. This inevitably is going to cause a high degree of developer visible change. > >> The relationship between being in UserList and having effective root >> access to the machine is poorly documented, and poorly understood. I >> suspect that this discussion has come as an unpleasant surprise to >> many people. If you add into the mix the extremely weak authentication >> and connection security that protects it from external attack, then I >> think that this is a hole we should be removing from the default >> install as soon as possible. > > It's also existed for the past 10+N years. That's not an excuse to keep > it around, but it's not like this is anything new. Our encryption technologies are significantly more vulnerable than they were 10 years ago. The threat profile of the Internet has changed beyond recognition in that time too. > S. _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
