Russ Allbery <r...@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 remove: * --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 (r...@stanford.edu) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info