[OpenAFS-devel] release-team meeting minutes 2013-08-14

[Stephan Wiesand]

Log: =
http://conference.openafs.org/release-team@conference.openafs.org/2013-08-=
14.txt

Attendance:

* Andrew Deason
* Ben Kaduk
* Derrick Brashear
* Jeffrey Altman
* Mike Meffie
* Stephen Quinney
* Stephan Wiesand

=3D=3D Potentially contoversial changes to be included in 1.6.6 =3D=3D

The list compiled by Andrew ( =
http://gerrit.openafs.org/#q,branch:openafs-stable-1_6_x+starredby:1000008=
,n,z ) and already discussed in June ( =
http://conference.openafs.org/release-team@conference.openafs.org/2013-06-=
12.txt ) was revisited.

* 6266 (Interrupt RX calls accessing offlining vols) can wait
* 6272 (unix: giveupallcallbacks at shutdown) needs a runtime switch, to =
be implemented
* 9420 (viced: Enable NAT ping on hosts) will be in pre1; if there are =
no positive test results, we'll consider reverting it
* 9485 (viced: Restrict RXAFS_FlushCPS to administrators) should go in
* 9390 (libafs: fs flushall for unix cm) should go in
* 9470 (Fileserver: Add the /vicepXX/NeverAttach flag to skip mounting a =
partition) should go in
* 9451 (volser: Do not reset copyDate in ReClone) lacked review
* 9571 (bozo: retry start after error stops) will be reworked by Mike to =
cap the wait times
* 9471 (ihandle: Remove ih_sync_thread) will not go in soon, since for =
now we have the runtime configurable behaviour
* 9477 (volser: preserve stats over reclones and restores) should go in

Some of those require some other changes before they can be merged, =
which typically shouldn't change behaviour and are rather lightweight.

=3D=3D Getting rid of the backlog =3D=3D

The remaining ~70 changes in gerrit waiting for being merged onto the =
stable-1_6_X branch are mostly bug fixes or supporting changes that =
shouldn't change behaviour. This backlog should be shrunk since it's =
tideous to keep track of, constitutes skew w.r.t. master and requires =
many changes to be rebased before they can actually be merged.

In the discussion it became clear that we don't want to lower our =
standards for code review for these outstanding changes just to catch =
up. The release manager will have to issue review requests where =
necessary. A time window of one week to at least say "it should be =
looked at more closely" seems reasonable.

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