hostap-1.0-rc3 update

[Kel Modderman]

Hi Jouni,

> On Thu, Feb 16, 2012 at 06:16:11AM +1000, Kel Modderman wrote:
> > Are these release candidates going to be formally released for testing or
> > only tagged in git as development milestones?
> 
> In the past, I have not really seen any significant testing of
> pre-release builds regardless of whether they have been just tags or
> release tarballs and I'm not sure whether there would really expect
> that to be any different now.

Fair enough.

> 
> > Bjarke Istrup Pedersen asked the same question on the 02/02/2012 without
> > answer and I think other distribution maintainers of hostap software could
> > benefit to know also. For myself, I have to see how the hostap release fits
> > into the Debian/Ubuntu cycle, and the lack of end user testing of release
> > candidates make me a bit more nervous than usual.
> 
> The exact snapshot of the rc1 or rc2 have probably not received much end
> user testing and I'm not really expecting any of these release
> candidates really to get much such testing. However, various snapshots
> from hostap.git over the last six months have been used in large numbers
> of end user products, i.e., have went through release testing by
> multiple companies and are in the hands of end users now. Sure, these
> are not completely identical to what is in hostap-1.git at the moment,
> but there are some very similar snapshots that have went through
> significant testing.
> 
> What kind of criteria do you have for release testing for Debian/Ubuntu
> purposes?

wpa_supplicant must be in good shape by June this year to enter Debian's next
milestone (wheezy), and Ubuntu would sync wpasupplicant from Debian shortly
after, which means:

* refresh patch series, push unsubmitted and relevant patches to you
  <http://anonscm.debian.org/viewvc/pkg-wpa/wpasupplicant/trunk/debian/patches/>

* figure out what has changed since 0.7.3, which has been around for 12 months,
  adapt to changes in build system, activate new features, get rid of deprecated
  features or plan to do so

* compile on all support architectures, weird ones like kfreebsd often present
  build failures. Often requires assistance from a porter, and they can't assist
  until the package is in the archive, usually

* ensure integration with Debian-Installer is not disrupted by changes or
  activation of new features. New features requiring linking with libs require
  coordination with lib maintainers too (eg. libnl3). Integration with the
  installer also means new wpasupplicant package versions require coordination
  with other teams for each new release, it also gets "frozen" very early on

* field a few bug reports after the new version hits users disks and their wifi
  breaks and the world implodes, squashing false positives and forwarding any
  genuine bug reports and looking for/applying fixes

So I guess most of my criteria concerns building wpa_supplicant rather than
runtime. Am expecting 1.0 to have quite a large delta to 0.7.3 and these build
related concerns can take a bit of time, co-operation and patience to sort out
if things go bad. Getting some of these issues ironed out during the RC phase
of your software release allows us to sneak in a few patches that might pop up
before the final release is made and people start concentrating on the future
plans again.

Of course we could fire up git and make a snapshot but I guess I'm just used to
having a clear and defined reference point. In the new release plans of this
year it was that reference point which has remained unclear so far.

Thanks all for working on hostap, and its release process, the effort is very
much appreciated.

Thanks, Kel.