[OpenAFS] Re: OpenAFS for Windows development road map

[Christopher D. Clausen]

Jeffrey Altman wrote:
> Nathan has put forward an idea that has been supported by all
> respondents that involves a multi-staged implementation.  I'm going to
> associate dates with some hypothetical releases because I think the
> version numbers are somewhat irrelevant:
>
>  * Nov 2005 - Stable Windows client without byte range locking
>
>  * Jan 2006  - Stable Windows client with optional but disabled byte
> range locking
>
>  * Apr 2006 - Stable Windows client with byte range locking that can
> be disabled
>
>  * Jun 2006  - Stable Windows client with byte range locking that is
> mandatory to use
>
> which differs from the original proposal of:
>
>  * Nov 2005 - Stable Windows client without byte range locking
>
>  * Jan 2006 -  Stable Windows client with byte range locking that is
> mandatory to use

What exactly is the complaint?  The available amount of time to make the 
changes (a few months)?  Or the timing of the period in which the 
changes will need to be made (middle of school year, winter holidays, 
etc.)?

-----

I'll likely get flammed for this, but I am of the opinion that forcing 
cells to make changes now (the "original proposal" above) is the best 
idea.  Anyone who thinks that it is going to cause problems and require 
large scale ACL changes is correct, but at some point you are going to 
need to make these changes anyway, assuming you want to have some other 
new functionality that will be available in the Windows OpenAFS client. 
Assuming that you wish to grow your usage and acceptance of AFS amoung 
your users, the best time to make such changes is right NOW as you'll 
only have more users to worry about in the future.

I'd also like to say that Jeffrey Altman has contributed quite a bit to 
the Windows client.  The performance has improved so much that I can 
generally even use encryption (fs setcrypt on) now and not notice the 
additional overhead.  Yelling at him for implementing new features and 
fixing long standing problems is NOT what should be happening.  If you 
feel that some new feature is going to seriously hinder your users or 
your cell, perhaps you should be maintaining your own builds that have 
this functionality disabled (I assume it can be trivially disabled at 
compile time?) and point your users to them.  This likely won't work for 
smaller cells, but then smaller cells should be able to make the needed 
locking changes rather quickly.

Forcing the rest of the world to use an "unstable" development client is 
NOT the way to do things.  Many sites won't even bother to test 
development versions and my users are generally scared of "unstable." 
AFS usage will not grow if smaller cells (such as mine) cannot rely upon 
an up to date client (with the latest features) being available on the 
OpenAFS website.  (Us smaller cells don't have the resources to hire 
developers to maintain a local build.)  Users don't want to read through 
all the different config options availble and don't want to check 
specific version numbers.  I get enough questions right now about if the 
MSI or the EXE installer is the correct one to use.  I'd hate to see 
what would happen if the version numbers start to change between the 
different OSes, not to mention having multiple "stable" clients linked 
from the main page with descriptions about file byte range locking and 
the like.  Most users will be confused and go back to scp, samba, or nfs 
which is certainly NOT what I want to support.

Now I could maintain my own website and mirror of the binaries that I 
want people to use, however if I don't update my site (and I often 
forget to do this now) users will not be obtaining the latest client. 
And I'd hate to think what would happen when users access things in 
foreign cells where one cell assumes one level of functionality and 
another does not.  I don't know of any cases where such problems have 
occured in the past, but I don't want to encourage it with multiple 
stable versions being available.

One could say that I have not been an AFS admin long enough, that I only 
have 300 users, 1TB of disk space, 5 servers and that my cell is too 
small to matter to the AFS community and you may be right.  However, if 
the world-wide use of AFS is going to grow (this is the ultimate goal, 
is it not?,) the smaller cells are where the growth needs to happen and 
every effort should be made to see that this growth occurs.

-----

I'm guessing that someone can counter all of the points I made above 
with:

1) I need a "stable" client so that I can test a massive roll-out for 
the next few years, not a GNU/Linux kernel like "lets add new features 
because we can" constantly moving target.
2) I don't care about OpenAFS community growth.  I need it to work in MY 
cell for MY users.  All you AFS evangelists be damned.
3) There essentialy has been a different Windows client version for the 
past year or so, whats wrong with that?
4) I have hundreds of servers and tens of thousands of users and have 
been an admin for decades.  My opinion matters more b/c I'm a larger 
user of OpenAFS.
5) You can maintain your own binaries just as easily as the rest of us.

<<CDC
-- 
Christopher D. Clausen
ACM@UIUC SysAdmin