[OpenAFS-devel] release-team meeting minutes 2014-04-09

[Stephan Wiesand]

Log: =
http://conference.openafs.org/release-team@conference.openafs.org/2014-04-=
09.txt

Participants:

* Andrew Deason
* Ben Kaduk
* Daria Brashear
* Marc Dionne
* Mike Meffie
* Simon Wilkinson
* Stephan Wiesand

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

Marc tested the 1.6 head against mainline yesterday, and we're still =
good. The merge window for the next Linux release is not quite over yet =
though.

=3D=3D Problem reports =3D=3D

Linux stack overflows (RT #131831):

Mike is working on a couple of additional changes that should help. =
We'll look at the whole bundle, including 10964, before deciding =
whether/when to pull these up.

RT #131846 (vos listvol localhost segfault):

Not actually present on the 1.6. branch.

=3D=3D 1.6.7 security release =3D=3D

OpenAFS 1.6.7 was released and announced during the meeting. This is =
probably how we should handle future security releases too.

=3D=3D 1.6.8 release =3D=3D

Gerrit 10987, a build fix for FBSD which was actually used for the pre1 =
binaries, was merged during the meeting.

Gerrit 10984 (afs: Raise fake free space reporting): ok for 1.6.x, but =
not after pre1. Postponed to 1.6.9.

Disabling hot threads: Not for 1.6.8, probably not for stable at all. =
Stephan to give it a try, and bring it up again if performance =
improvements are significant.

No further candidates for inclusion at this time. The next prerelease =
(pre2, including the changes from 1.6.7) is planned for early next week.

=3D=3D Testing =3D=3D

No news yet. To be discussed next week.

=3D=3D Next stable branch(es) =3D=3D

Keeping the release schedule for Windows independent of that for the =
other platforms seems to be generally accepted. There are different =
ideas regarding the details though.

One possible model is to make 1.9 the next stable release branch for =
Windows and 1.8 the next stable release branch for the other platforms. =
This would be a continuation of the 1.7/1.6 situation we had in the past =
years, and preferred by some of the participants.

Another idea is to distinguish between these branches more clearly than =
just by odd/even numbers, by giving them different names, which is =
preferred by some of the other participants mainly because it's less =
confusing to users.

[Another one seems to be to give both different even release numbers, =
since users tend to associate "odd" with "unstable"].

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