[OpenAFS-devel] Proposal for capabilities support in Unix client 1.4.x

[Jeffrey Altman]

Harald Barth wrote:
> Ehm, 1.5/Linux is not fit for production, so according to be useful in
> production, the OSD stuff must be made against 1.4.

People said exactly the same thing about 1.2 when we were trying for
years to get 1.4 stable.  If you spend all of your effort focused on
the past we will never get to the future.  I understand your desire
to deploy RxOSD today.  In fact you are deploying RxOSD on 1.4 today
with private patches.   So why do you care of OpenAFS ships it in 1.4
when we are attempting to migrate stable to 1.6?

Why do you want a 1.6?  Well for starters it contains three years of
effort focused on improving code quality by adding prototypes almost
everywhere and (mostly thanks to Simon Wilkinson) reducing the number
of compile time warnings from over 30,000 to under 1,500.  Now 1,500
is still too many but most of these are 64-bit time_t related or signed
vs unsigned comparisons which are much less concerning than the wide
variety of "uninitialized variable" and "pointer vs int" and "pointer
to wrong struct" warnings that exist in 1.4.

If you the 1.5 code base is buggy, file bug reports against it so that
they can be fixed.  If you believe that 1.5 code base is so bad that
you can never ever deploy it, please explain why you think that is the
case and how you think we need to change it.

The situation the gatekeepers find ourselves in is that we have one
group of users on the left saying that they want DAFS but don't want
RxOSD, another group that says they want RxOSD but not DAFS, another
group that says they want Disconnected Mode but neither RxOSD nor DAFS,
another group that says they are happy with 1.4 and do not want to
risk any breakage in their environment caused by any of these large
new features.   It is impossible for everyone to get exactly what they
want.

The compromise is that OpenAFS has a set of policies that govern
releases.  The stable series which is currently 1.4 does not get
significant quantities of new code.  All new code goes into the
development series (currently 1.5) which then matures and becomes
the next stable series.  This has been true since OpenAFS began in
2000.  You take for granted that the OpenAFS Windows clients are
built off of the development branch.  Why is that?  It is because
all of the "extremely stable" code that has been deployed on tens
of thousands of systems over the last three years to support 64-bit
Windows, Vista and Server 2008 is still considered too risky to
pull into the 1.4 series.

Everyone thinks their situation is a special case or that their
source code is better written and tested than anyone else's.  The
reality is that isn't true.  OpenAFS is a community effort.  We all
play by the same rules and we all work together to develop a better
product.  Continuing attempts to pull everything into 1.4 is only
going to cause 1.4 to be 1.5 and cause everyone to be unhappy.

The way forward to develop on 1.5 and test 1.5 and file bugs against
1.5.  Anything else will simply result in deadlock.

Jeffrey Altman