In message <[EMAIL PROTECTED]> Mike Meyer writes:
: Warner Losh writes:
: > In message <[EMAIL PROTECTED]> Mike Meyer writes:
: > : The nasty downside of the the module system is that people who don't
: > : adequately test module code before checking it in will screw up kernel
: > : builds for kernels that don't need that code.
: > But I did test it.  But I had an uncommitted file on my machine...
: Won't the 'cvs diff' command tell you about such things? If not,
: that's yet another argument for ditching cvs in favor of something
: without so many flaws (like Perforce).

Not when the files are in multiple different directories and you have
mutliple patches cooking in your tree.  I committed files in
sys/pccard, but they depended on one in sys/dev/pccard which I
honestly thought I'd checked in with an earlier newcard fix.  I'd been
running the patches long enough that I basically forgot.  This was
clearly my fault.

: > : Since you probably don't need the oldcard module. Just comment it out
: > : of /usr/src/sys/modules/Makefile, and rebuild the kernel. You may want
: > : to comment out pccard as well.
: > Or you can just update your sources.  There was a 8 hour window where
: > this was broken...
: Well, it was still broken as of about 30 minutes before he asked the
: question. I'd look at it for trivial fixes, then just quit trying to
: build it because I wasn't going to need it.

No.  It is not still broken.  I committed a fix for this a while ago
(like Friday Morning after breaking it late Thursday night) and have
done a buildworld and a kernel build on a different machine since then
on fresher sources.  If it truely is still broken, I need to know what 
you did.

In fact, I did an cvsup and a cvs update and was able to build a
kernel and modules w/o any problems on my -current box.

: I didn't mean to finger you particularly. It's just a bit upsetting to
: realize that I can't remember the last time I managed to do an update
: to -current without some kind of breakage. I realize that -current
: isn't guaranteed to build, but that's a bit ridiculous. I mean - I was
: pleasantly surprised that I could build the world first time out. To
: find the kernel breaking for a module that I have no absolutely no use
: for on this machine was a bit upsetting.

Well, that's the break's of -current.  sometimes things are broken.
Sometimes when you update, you get burned.  Usually it just works.

: I'm beginning to wonder if I shouldn't use -stable as a buffer, and
: just let the committers deals with things not being up to -current. Or
: maybe check to see if the other *BSD's aren't a bit more demanding of
: committers.

I know that you are frustrated, but I think that's unfair.  You'll
likely find that the other BSD's are just as bad at times as we get
around here.  At least that's my firsthand experience with them as a
committer.  There was a period of about 6 months that every time I
went to upgrade the OpenBSD/arc installed on my Deskstation rPC44,
someone had broken something and I had to fix it before it would

If you aren't a developer or have another compelling reason to track
-current, track -stable.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to