[OpenAFS-devel] release team meeting minutes 2014-08-27

[Stephan Wiesand]

Log: =
http://conference.openafs.org/release-team@conference.openafs.org/2014-08-=
27.html

Participants:

* Andrew Deason
* Ben Kaduk
* Daria Brashear
* Jeffrey Altman (not present, but input received by mail)
* Mike Meffie
* Simon Wilkinson
* Stephan Wiesand

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

3.17-rc2 was released. We don't currently know whether we need to take =
action.

=3D=3D 1.6.10 Finishing touches =3D=3D

11392 (fixing out-of-tree-builds) is ok to merge, unless there's =
negative feedback soon.

11402..11404 (needed for i386 FreeBSD 10): the same

11380 (still on master) seems to take longer and may have to wait for =
1.6.11

All these are either build fixes or only apply to a debugging tool or =
debug mode, and are generally low risk. Thus, no pre2 is required to =
include them in the final 1.6.10 release after the usual review process.

11433..4 (vos clone fixes brought up by Jeffrey): The former seems to =
need some more review and discussion. The latter is a behaviour change =
and thus would warrant a pre2. Since these are very old problems, =
postponed to 1.6.11 (or possibly pre2, if we have to issue one for other =
reasons).

=3D=3D 1.6.10pre1 testing =3D=3D

No negative reports yet. Some of Andrew's volunteer sites reported =
success on various Linux distributions, and a few more are still =
expected to report.

=3D=3D Problem reports (issues to fix in 1.6.11) =3D=3D

The "bos removeuser" problem reported in =
https://lists.openafs.org/pipermail/openafs-info/2014-August/040942.html =
can probably at least be hacked around. Ben's first attempt to backport =
9986 is 11436 and was uploaded during the meeting. It failed to build on =
AIX and Solaris 10 though.

=3D=3D 1.8 branch (next stable series) =3D=3D

The attendees still present (which probably excludes Daria) agreed that =
we should set a deadline for branching September the 24th. Cleanups =
(like a whitespace cleanup already submitted by Mike) should happen =
before if possible, and it should also be checked before that the master =
branch generally builds and runs.

Ben's rxgk changes will largely need to be rebased anyway, so cleanups =
are no problem in this respect.

Jeffrey thinks that branching shouldn't be done before it seems likely =
that 1.8 prereleases can become production releases within two months.

Simon warns that there are a number of loose ends (libtool, roken, =
hcrypto, packaging) and that there should be some commitment to work on =
1.8 to make sure it won't languish for a long time, and that maintaining =
multiple branches will cause overhead.

Stephan thinks that fixes needed to get 1.8 into prerelease state are =
more likely to get done once the branch exists, and we thus shouldn't =
wait longer even if master is not in perfect shape end of September.


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