[OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Russ Allbery rra@stanford.edu
Tue, 15 Jun 2010 18:47:15 -0700

Russ Allbery <rra@stanford.edu> writes:

> After 1.6, we currently have the following plan.  This is definitely
> open for discussion and is not set in stone, but it's our current
> intention.  Please send feedback (preferrably to openafs-devel, since I
> believe that's where most of the discussion will be).

As was pointed out to me in private e-mail, this covers what we're
*adding*, but not what we're *removing*, and I should probably say
something about that as well.  As above, this is a proposal and isn't
final.  Please send feedback to openafs-devel (or openafs-info if that
seems better).

I'm aware of the following (largish) things that we want to deprecate or

* --enable-fast-restart and --enable-bitmap-later are earlier attempts to
  solve the problem that is solved in a more complete way by demand
  attach.  Demand attach will be available in 1.6 but not enabled by
  default.  These two options will conflict with demand-attach; in other
  words, you won't be able to enable either of them and demand attach at
  the same time.

  At the point at which we make demand attach the default, rather than
  optional behavior, I believe we should remove the code for these two
  flags.  I think that should be for either 1.10 or 2.0 based on
  experience with running 1.6 in production.  In the meantime, please be
  aware that most of the developers don't build with those flags by
  default and the code is not heavily tested.

  This code is not enabled by default, so if you're not compiling yourself
  and passing those flags to configure, you're not using this and don't
  need to worry about it.

* As we've stated for some time, at the point at which we release an
  OpenAFS 2.0 with rxgk, we intend to deprecate kaserver.  What I believe
  that should mean is that, in OpenAFS 2.0, we will require passing a flag
  to configure to build kaserver and all the related code for Kerberos v4
  support in the tree (kaserver, kas, kpasswd, the PAM modules,
  tokens.krb, pagsh.krb, klog, klog.krb, and doubtless some other things
  that we find hiding).  Unless someone steps forward before that time and
  updates uss to make it useful in a non-kaserver environment, I believe
  we should disable building of uss at the same time.

  At that time, we will stop building that code for the binary
  distributions from openafs.org, and I will also stop building the client
  packages with that code in Debian (Debian never included kaserver).

  We will then remove that code entirely after (at least) a year after
  2.0 is out, which if we stick with our intended time-based release
  practice will mean 2.4.

* In the long term, we want to remove LWP and build all parts of OpenAFS
  against POSIX pthreads.  This has no time frame yet since it depends on
  other work that's not yet complete.  It obviously depends on completion
  of the pthreaded Ubik work, which I don't believe is in a state that's
  ready to recommend as of 1.6, so will continue to be optional in that
  release.  Once that is ready to be the default, we then need to do
  considerably more work to build all the rest of the tree against POSIX
  pthreads and not LWP before we can remove LWP.  This is still therefore
  quite some distance out.

Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>