[OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule
Tue, 15 Jun 2010 18:47:15 -0700
Russ Allbery <email@example.com> 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
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 (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>