future wpa_s/hostapd release plans

[Johannes Berg]

Hi all,

For those who were at the summit -- this is mostly an announcement for
what we discussed there. I may have gotten things wrong, so please
comment and let's hammer this out, then later when we've agreed on "the
plan" I suggest things end up on the website.

For those who weren't at the summit -- in a nutshell: a lot more people
are starting to rely on upstream releases so we need to have more
predictability in the releases. Also, Jouni's overloaded as is, and
really needs help :-)


So the plan is roughly this:

Every 6 months, the current hostap.git repository forks into a new
hostap-x.y.git repository. This repository will be maintained by
different community members, we've volunteered for the first one and TI
indicated they'd be willing to help with the second one.

The hostap-x.y.git repository will be on w1.fi (for all intents and
purposes, the technical implementation may require whoever maintains it
to have their own version somewhere and git synchronising things).

After the fork, a stabilisation period begins, concluding with the
release of "x.y.0" after about 4-8 weeks. This may involve multiple RCs,
e.g. "x.y.0-rc1" per the discretion of the maintainer.

Each one of these stable releases will be maintained for at least a
year, so whoever commits to maintenance will commit to maintaining that
tree for a year from the .0 release.

As far as patch flow goes, for the first 6 months the current stable
tree ("x.y") will have fixes flowing from the development tree into it,
this may require re-writing fixes of course. After 6 months, this
becomes "oldstable" and then only picks up patches from the new "stable"
tree (x.y+1), after another 6 months it is either abandoned or maybe
continues to be maintained for really critical fixes. This patch flow
ensures that fixes are vetted appropriately and the stable trees never
have anything that isn't in the development tree.

Oh, and because this is a change, Jouni proposed calling the first one
that will come out of this "1.0" (first release 1.0.0), followed by
"1.1". (or did you mean 1.0 being the first release, followed by 2.0,
and fixes as 1.1, 1.2, ...?)

That's all. Essentially, the maintenance of the stable and oldstable
branches will be taken off Jouni's shoulder and be more predictable.



Now -- the bad parts:

First of all, when will the first branch happen? I'm not sure -- we need
to put infrastructure in place on our side to make it happen and
familiarise ourselves with the release scripts etc., so that might take
a little while. I'm thinking maybe some time in November, and then the
next ones can be in May 2012, November 2012 etc.

Secondly, we don't have a fully functional test bed, so when/how do we
call what branched as 1.0 actually release-worthy? Jouni -- what's your
process there? Just "generally I'm happy"?

That's all, please comment :-)

johannes