On Jul 27, 2005, at 5:06 AM, Dieter wrote:
> Wolfgang writes:
>> How much should one worry that the undocumented built-in ethernet  
>> can't be
>> supported when gigabit ethernet pci cards are $25?
> Quite a bit if you don't have extra PCI slots.

If you have no expansion capabilities on a system, it is highly  
advisable to check beforehand whether a specific NIC, motherboard, or  
whatever is supported well under NetBSD.

If nobody answers, well, some brave soul will have to be the first to  
try it, and the first to add PCI device ID's to the drivers (along  
with whatever else is needed), so that everybody else can benefit  
from the work.  Of course, one could always purchase from vendors who  
actually provide some kind of support for NetBSD.

And if you don't ask, well, you've chosen to be surprised.  :-)

> Robert writes:
>> I for one am bothered by the state and pace of which NetBSD is  
>> coming along
>> (especially when the driver for the BCM5751 has been in NetBSD- 
>> current since
>> sometime last year)!
>
> Here is one problem that might be fixable.  I also see many things  
> sitting
> in -current while release after release come out.  Simple, safe,  
> things that
> need little if any testing.

I don't have a good handle on NetBSD release engineering yet, but  
software version numbering is an inexact science at best, just like  
logistics.

It's useful to change the OS major version # whenever libc or other  
aspects of the system API change in such a critical fashion that it  
is advisable to recompile all software for the new OS version.  Sure,  
compatibility shims exist, but system VM takes twice the hit for the  
standard shared library overhead.

However, some people like having a new major release each year, or  
even prefer the Win98/Win2000/Win2003 naming convention of using  
yearname as the major version #.  I'm not that found of it myself,  
although I suppose it makes sense for certain inherently time-fragile  
software like accounting and tax-filing software, or for online  
encyclopedia's and such.

> Problem reports with tested fixes included sit around forever and  
> don't even
> get checked into -current much less a release, while release after  
> release come out.
> What is the point in submitting a PR with a fix if it never gets  
> checked in?

A good time to point out that a PR has been sitting too long is when  
someone else asks about the problem the PR fixes.  You can at least  
make the second person running into the problem happy that it has  
been solved.  :-)

> What is the point of having releases and the time&effort they  
> involve when bugfixes
> and new drivers sit around in -current or worse, in an open PR?   
> Example: a simple
> one line fix for a kernel panic was checked in, but didn't make it  
> into 2.0.2.  What
> the heck is the criteria for getting into a release if a simple one  
> line fix for a
> kernel panic doesn't qualify?

Maybe the magic phrase "a pullup to version X.Y is requested" in the PR?

-- 
-Chuck