cvs commit: src/sys/kern kern_tc.c src/sys/net rtsock.c src/sys/netipx ipx_proto.c src/sys/netnatm natm_proto.c

[David O'Brien]

On Mon, Sep 12, 2005 at 10:16:00AM +0100, Robert Watson wrote:
> Supposing for a moment that I didn't work for a large CPU manafacturor, 
> but instead had a moderately well-configured desktop system, and that 
> instead of having one source tree I worked on, I were a kernel developer 
> who had 12 active development branches with various kernels, then the math 
> settles out a little differently.

Suppose that thru a long multi-month discussion with the TRB and parts of
Core a matrix was created what was officially supported of what builds on
what.  And also stated what was should be kept building on what if
reasonable to do so.  And stated what wasn't supported.

The build situation you championed wasn't even contemplated - it isn't one
we'd run into to even consider having it in the matrix.

I know for a fact that a RELENG_5 config(8) won't config a -CURRENT
kernel.  So you must have built a -CURRENT config(8) on your RELENG_x box
(or be prepared to).  You could also build -CURRENT gcc+binutils on your
RELENG_x box and install it for use in building HEAD kernels.


> On my desktop (P4 1.8GHz, 512MB), it takes 15 minutes per kernel tools
> build, which assuming I built them on the three machines sequentially,
> would result in spending 9 hours rebuilding kernel tools as a result of
> introducing dependencies on compiler tweaks before merging them.

Honestly, a 1.8GHz Intel (or AMD 1800+) desktop CPU is 4 years old.  For
some one building 12 active branches a day, I think you would be more
than justified in asking for a more powerful desktop at
http://www.freebsd.org/donations/wantlist.html With both Intel and AMD
have dual-core desktops - allowing you to have a cheap SMP machine, its a
good time to ask on wantlist.html.


> So the difference between it working may be gravy to you, but it's the 
> difference between spending several days of my FreeBSD time chasing build 
> tool changes over a dozen branches and several machines and spending those 
> days doing productive work.  Which isn't to say that progress shouldn't 
> happen, just that a minor change in the order of commits would have saved 
> me a lot of time.

There are 100's and 100's of FreeBSD commits that if ordered or done
slightly differently would have saved me hours and hours and hours.
That, unfortunately, is the life of a committer in FreeBSD'ville.


> Just because you don't know how to request MFC's from the release 
> engineering team, which typically has a turn around time of less than a 
> day, doesn't mean I shouldn't expect you to know how to do it :-).

Feh.  I don't know what world you live - this doesn't at all match my
experience over the past two years.  Maybe requests from members of RE
gravitate to the top of other RE's inboxes where they are seen and
answered... ;-)   My experience is one of missed and forgotten requests.
Or requests denied by one RE and approved by another, after poking them
individually.

-- 
-- David  (obrien at FreeBSD.org)