[OpenAFS-devel] release-team meeting minutes 2013-11-06

[Stephan Wiesand]

Log: =
http://conference.openafs.org/release-team@conference.openafs.org/2013-11-=
06.txt

=3D=3D Participants =3D=3D

 * Andrew Deason
 * Ben Kaduk
 * Derrick Brashear
 * Jeffrey Altman
 * Marc Dionne
 * Mike Meffie
 * Stephan Wiesand

=3D=3D 1.6.6pre1 =3D=3D

=3D=3D=3D Linux kernels =3D=3D=3D

3.12 was released. Marc tested against it and we're still good.

=3D=3D=3D OS X Mavericks =3D=3D=3D

We may have a fix for the symlink issue soon. A Mavericks installer will =
take longer. Pre1 shouldn't block on this, but 1.6.6 final should. If =
current thinking is correct, the required change will be low risk and =
thus ok to include in between pre1 and pre2 or even between pre1 and =
final.

=3D=3D=3D BSD fixes =3D=3D=3D

The last pending BSD fix was +1'ed by a gatekeeper and merged during the =
meeting.

=3D=3D=3D Linux namespace fixes =3D=3D=3D

These were pulled up to 10247/8 by Anders before the meeting. They will =
be required for Ubuntu 14.04 (an LTS release) and most likely - sooner =
or later - for Fedora as well. After review, we'd like to include them =
in the 1.6.6 release. [Please review gerrit 10247/8, and the fix on =
master in 10433, if you can]

=3D=3D=3D Cache truncation fixes =3D=3D=3D

These were merged on master recently. They prevent an afsd thread from =
going into an infinite loop. Observed on Solaris only. The changes have =
run in production on the affected site for several months. Ok to include =
in 1.6.6. [Since the meeting, they have been pulled up to 10431..10436 - =
please review if you can]

=3D=3D=3D RT #131737 (afs/afs.h) =3D=3D=3D

Problem has existed for all of 1.6, no easy solution at hand, but there =
are workarounds for known problems. Probably shouldn't be touched in =
1.6.x at all.

=3D=3D=3D RT #131766 (Solaris 5.10/x86 build of 1.6.5.1) =3D=3D=3D

Problem has existed for at least all of 1.6, no trivial solution at =
hand. Probably shouldn't be touched in 1.6.x at all.

=3D=3D OpenAFS 1.8/1.9/1.10 =3D=3D

Jeffrey laid out his ideas:

 * create a 1.8 branch after the next 1.7 release
 * branch 1.9 from master end of November
  * at this point, 1.6.x should adopt a much more restrictive policy for =
accepting changes
  * estimate to get 1.9 to production quality: 4-6 months=20
  * at that point, it will become 1.10
  * 1.9.x releases will be issued to allow testing the new major release
  * the 1.9 development process will mirror the current 1.6 one (submit =
to master, pull up to 1.9 branch)
  * primary benefits of 1.9/1.10:
   * bring windows back into the same release series as unix
   * pthreaded ubik
   * rx improvements
   * libtooling for perl-afs
   * and it will allow rxgk to break master for a while

--=20
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany