[OpenAFS-devel] release-team meeting minutes 2014-06-11/18

Stephan Wiesand stephan.wiesand@desy.de
Wed, 25 Jun 2014 16:11:55 +0200


[just lumping the two meetings together, since too much has happened =
since]

Logs:
 =
http://conference.openafs.org/release-team@conference.openafs.org/2014-06-=
11.html
 =
http://conference.openafs.org/release-team@conference.openafs.org/2014-06-=
18.html

Participants:

* Andrew Deason
* Ben Kaduk (June 11 only)
* Daria Brashear
* Jeffrey Altman
* Jeffrey Hutzelman (June 18 only)
* Marc Dionne
* Mike Meffie (June 11 only)
* Stephan Wiesand

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

Marc reports that we're ok for the final 3.15. 3.16 will require pullups =
of gerrit 11302 and 11303 (yet to be accepted on master), and is likely =
to be released ~ mid August.

We're likely to be good for RHEL7 GA, but it hasn't been tested.

Discussions in both meetings suggest that we shouldn't ship transarc =
paths based packages for newer Red Hat platforms (RHEL7+, F21+), and =
that we should leave packaging for those to downstream altogether. [A =
discussion on -info supported that idea, but I'm not convinced that =
there's a viable solution yet].

=3D=3D 3.10 [or whatever will be the next not security only one] release =
=3D=3D

=
http://gerrit.openafs.org/#q,status:open+project:openafs+branch:openafs-st=
able-1_6_x+topic:cmd-catchup,n,z was turned down. We'll rather have a =
1.6-only version of gerrit 11214.

Volscan/volinfo can go in (not "core") - barring review.

So can the parallel make changes - barring review.

Ben's venus/test build change can go in - barring review.

Stack reduction changes can go in - barring review. There are some =
concerns regarding the performance impact of all those tiny memory =
allocations.

Perry's "avoid duplicate messages" stack can go in - barring review.

Gerrit 11205 (linux: dont ignore kmod build errors) can go in - barring =
review.

Marc's "Speed up afs_CheckTokenCache" still needs to be pulled up to =
1.6.x [done: please review 11307]

=3D=3D Next stable branches =3D=3D

We'll create the next stable branches as soon as Simon is available for =
it, probably early July, knowing that it may require some work to make =
them usable.