[pkg-wpa-devel] Bug#374342: Needs more testing

[Kel Modderman]

Reinhard Tartler wrote:
>> Madwifi will eventually propagate to testing, and the wpa_supplicant 
>> version in same archive will not support it.
>>     
>
> You mean Version 0.svnr1644.0.9.0-2? Perhaps we can coordinate
> transition of the two packages? On the other hand, we can tell users to
> install wpasupplicant .deb from unstable in their testing system.
>   

I do not think that extra co-ordination would be worth the effort here, 
I am sure we can guide these people to the correct sources during this 
relatively short period of time.

>   
>> Also, there have been no bug reports since last upload indicating large 
>> problems with functionality. (I realise it is still early days)
>>     
>
> I remember #373776, which was bounced from Elimar Riesebieter
> <riesebie at lxtec.de> to pkg-wpa-devel. Ok, this is a madwifi-ng bug. Bugs
> which directly relate from the 0.5 branch did not appear yet.
>   

That would almost definitely be madwifi specific (unfortunately).

> To bring up my reservations to this list (I already mentioned them on
> irc). I think the 0.5 branch is a bit dangerous, because:
>
>  a) the 0.5 branch didn't get as much test coverage than the 0.4 branch.
> Bugs are more likely.
>
>  b) Semantic changes in the code of new features, which are still under
> development. I fear that behavior changes may disrupt our package
>
>  c) config file changes like mentioned above.
>   

Ack.

>   
>> I am confident that the 0.5 series will be tagged as "stable" by Jouni 
>> before the time that Etch is released (quite a few months away yet, 
>> iirc), therefore, I'd like to concentrate more on testing and developing 
>> infrastructure around 0.5 before that time comes.
>>     
>
> Yes, afaik, etch is currently targeted for december this year. I think
> that we are both (well, espec. you ;) active enough to stabilize a
> wpasupplicant 0.5 for etch release. So yes, I mostly agree with you. I'd
> still appreciate if we could have the 0.5 branch tested for say, 2 more
> weekends and wait for reports. I don't expect many bugs, but I'm rather
> conservative for users of 'testing'.
>
>   

Yep, and I agree with the extended period of testing too.

Thanks, Kel.