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
[EMAIL PROTECTED] SysAdmin
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
