[OpenAFS] Re: "OpenAFS for Windows development road map" was Re: [OpenAFS] 1.4.1-rc2 build question

[Jeffrey Hutzelman]

On Saturday, December 03, 2005 01:26:57 AM -0500 Jeffrey Altman 
<jaltman@secure-endpoints.com> wrote:

> One of the points that I am attempting to make is that the rate of change
> in the Windows client is going to continue to out pace the rate of change
> in the Unix-based implementations for at least the next year as it
> continues to play catch up.   During this time there is going to be a
> significant impact on end-users with new user interfaces and behavioral
> experiences depending on which client the user chooses to install.

Great.  Adding significant new functionality and making major behavioral 
changes is what the unstable branch is for.  The stable branch is for being 
stable.

Prior to the release of OpenAFS 1.4.0, we essentially forced Windows users 
to run the unstable branch if they didn't want something that was horribly 
buggy and crashed a lot.  That was unfortunate, but necessary.

Now we _have_ something that's not horribly buggy and doesn't crash a lot. 
As we discover and correct new bugs, those fixes should be applied to the 
stable branch.  However, users who want these fixes should no longer be 
forced to run a constantly-changing unstable version in order to get them. 
Make major changes on the unstable branch.  People who want significant new 
functionality which hasn't been heavily tested and violates the principle 
of least surprise get to run the unstable version -- that's what it's _for_.

> The way I rationalize it is
> that the OpenAFS version number is tied to a set of functionality
> implemented in the servers.   As long as the server functionality does
> not change in a significant manner, the version number will not be
> bumped.

Rationalization indeed.  So, you feel you can make whatever radical changes 
you want to the client as long as there's not significant new server 
functionality?  I'm sorry Jeff, but "stable" means the _whole thing_ is 
stable, not the whole thing except the part you feel like completely 
rewriting.





> what incentive is there for you to upgrade your users to 1.4.1 as opposed
> to 1.4.0?   The bugs in the 1.4.0 client are so minor that simply
> obtaining a fix for those bugs if you are not actively experiencing them
> is not a reason to upgrade.

And if you are experiencing them, you should not be required to submit to a 
major functionality change to make the problem go away.


OpenAFS for Windows sucked for a long, long time.  You've spent a lot of 
time and effort making it stable enough for production use.  Now that we've 
reached that point, it's time to distinguish strongly between the version 
people _run_ in production use, and the version with all the fancy new 
features.  We can no longer afford to shove major changes down people's 
throats that they aren't ready for.

-- Jeff