1 # Notes related to an OpenAFS 1.8 branch
3 The current plan is to make a branch for 1.8 off of master on or about
5 This will allow all of the improvements and cleanup that have accumulated
6 on master to be in a stable release series, while letting potentially
7 destabilizing changes such as rxgk and pthreaded bos land on master to
10 A 1.8 release would also bring the possibility of using shared libraries,
11 which are now available with the use of libtool. Currently (on master),
12 all executable binaries are still linked mostly statically, and most of
13 the shared libraries that are produced during the build are not installed
14 to the destination tree. Exceptions are libafshcrypto.so, libkopenafs.so,
15 and librokenafs.so. We could consider installing more shared libraries,
16 and using dynamic linking for executables, either before or after the
17 branch point. Doing so would involve deciding on what sorts of ABI
18 stability guarantees should be provided.
20 The remainder of this page has three separate lists, for things to be
21 done before branching, things to be removed from the 1.8 branch after
22 it is created, and things to be removed from master after the 1.8 branch
25 Things to be done pre-branching:
27 * [done] Make roken, hcrypto, and kopenafs use libtool to build
28 * [done] Make sure libtool is used properly elsewhere, in particular to install
29 shared versions of libafsrpc and libafsauthent, which we ship in
30 1.6 but do not currently install on master
31 * [done] Relatedly, verify that the libraries we do ship do not depend on things
34 (Optional) Look at the feasibility of installing shared liboafs_foo,
35 and using dynamic linkage for the client utilities.
36 * (rxosd is not going to make it unless someone steps up to do the work;
37 we can't block the branch indefinitely on it.)
38 * Do install and run testing on various platforms; check for memory leaks
40 * Relatedly, check that the kernel module is properly built and loadable
41 on a variety of linuxen.
42 * [done] Draft Debian packaging (which will help with a lot of the libtool
44 * [done] Whitespace cleanup.
45 * Any other tree-wide cleanup that people want to get in.
47 Adjust the default behavior of configure (pthreaded ubik? more?)
48 * Beg and plead for documentation updates.
49 * [done] Tie the installation of the pam module to --enable/disable-kauth
50 * fix issues with HOST_TO_ZERO and tmay (see gerrit 11287/11290 and related)
52 Things to be done before 1.8 release (but not necessarily before branching):
54 * Go through outstanding changes against master and determine
55 which should get pulled in for 1.8
56 * Documentation fixes needed before release but not necessarily
57 before branch: KeyFileExt, converting keys from 1.6 to 1.8 format, ...
58 * Investigate volume header update issues; volume update time is not
59 changed by admin operations that alter metadata such as quota, which
60 could subsequently get lost.
61 * Investigate whether vos release -stayup should be removed.
62 * Investigate "lockless path through d_revalidate" for potential issues (?)
64 Things to be removed from 1.8 post-branch:
66 * `src/rxgk`; it is not going to be usable in 1.8
67 * `src/mcas`; it is not going to be usable in 1.8
69 Things to be removed from master post-branch:
71 * Several `tfoo` can probably be moved to just `foo`; things like
72 `tptserver`, `tvlserver`, `tvolser`, `tsalvaged`. I'm not sure whether
73 `tbudb` and/or `tbutc` are ready.
74 * push to empty out libutil as much as possible.
76 * it is tempting to remove kauth, but probably not possible due to agreements with IBM.
77 * `make dest` support? Pretty-please?
79 * non-DA fileserver and associated bitmap-later and fast-restart configure knobs