Re: HEADSUP usb2 (usb4bsd) to become default in 2 weeks.

Remko Lodder wrote:
> 
> On Dec 23, 2008, at 6:50 PM, Joe Marcus Clarke wrote:
> 
>> Wilko Bulte wrote:
>>> Quoting Rink Springer, who wrote on Tue, Dec 23, 2008 at 05:23:36PM
>>> +0100 ..
>>>> Hi people,
>>>>
>>>> On Mon, Dec 22, 2008 at 01:40:10PM -0800, Alfred Perlstein wrote:
>>>>> We're going to usher in the New Year with a new usb stack.
>>>>>
>>>>> Now is the time to test, test, test.
>>>>>
>>>>> It is also the time to point out anything missing from usb2 that
>>>>> is in usb1.
>>>>>
>>>>> In two weeks, on Jan 3rd I will switch the GENERIC kernel to use
>>>>> usb2.
>>>>>
>>>>> The old usb code will remain in case there is any fallout.
>>>>>
>>>>> Depending on how this trial goes we will hopefully move to the new
>>>>> stack entirely within a few weeks after bug reports start dying
>>>>> down.
>>>> For what it's worth, I think this is *way* too early to be even
>>>> considering this; there is still massive fundamental work being
>>>> performed on the new stack (which reminds me that I really should get
>>>> back to my permission patches soonish), but that is not the only
>>>> issue.
>>>
>>> Guys.. is there any reason why this needs to be rushed in over the
>>> Christmas
>>> break?  Getting it in the tree, fine.  But making USB2 the default so
>>> quickly does not appear to be proper engineering procedure.
>>>
>>> The days that CURRENT was broken for long periods is not something the
>>> project wants to get back to.  The discussions sofar do not make me
>>> believe
>>> this will be a smooth transition, it seems it will need testing and
>>> fixing for
>>> a reasonable (considerable?) period.
>>
>> Agreed.  For desktop users, sysutils/hal is currently broken with usb2.
>> It's on my todo list to fix, but I may not have time to do it in the
>> next two weeks.  I know this may seem minor considering other issues,
>> but people used to automounting USB media in their desktop won't think
>> so.
>>
>> Joe
>>
> 
> Given the amount of problems that there are reported on various sources
> (usb->serial converters not working etc), I think we should provide a
> base where at least 95% of the things that we ship are working by
> default. I have seen advises that we should disable some kernel builds
> and add stuff via modules. I do not think that is the way to go for
> something which people normally 'take for granted'.
> 
> I would like to see the code mature in the current form, gets it's
> developer attention and updates (and yeah there might be painful
> updates, even for hps, live with them in order to get this thing going
> as strong as possible).
> 
> In the past (imo) we had several project sites on www.freebsd.org that
> listed our projects, and the milestones to take and open items. Is it an
> idea to send doc_at_ (or me whatever) a list of open items that need
> attention, that we document on the site, and only change default
> behaviour if enough bullets had been fired (read: if enough items had
> been fixed). That way there is a hardcopy of what needs attention, it's
> clear for anyone which items that need attention, and if everyone steps
> up, there is no one that can complain that his arguments aren't listed
> there and no one that can say that he/she didn't know about the arguments.

I'll offer a different POV.  I think we should switch ASAP and resolve
open issues (so long as the old code is kept around for folks to fall
back on).  We cannot ship 8.0 w/ 2 stacks and delaying the inevitable
will only leave unknown issues closer to the release date and
potentially delay/extend the release process.  I said this when the code
was first committed and feel even more strongly now.  Of course all this
depends on developers stepping up and fixing problems.  IMO we cannot
depend on this code if it is treated purely as vendor-contributed code.

The only reason I can see for not switching are important regressions in
functionality (both in the kernel and user programs) or security issues.
 It sounds like there are reasons to not switch now but I think we need
to move ASAP.

	Sam