Re: NetBSD master CVS tree commits

[mjacob%feral.com@localhost (Matthew Jacob)]

>Generally, send to current or the list for that port, depending on
>the nature of the problem. Anybody who's been working on the code
>will be looking at those two lists.
>
>But on a project like this I don't think it's realistic to expect
>the entire system to build every night. I don't know anyone with
>a full set of platforms for testing (I am able to test on only five
>platforms myself, and only two or three are really fast enough to
>be practical), which sort of limits the degree of testing one can do.
>
>This is not to say that I don't think having someone attempting
>nightly builds is not a good idea. I've been meaning to start doing
>this myself for some time.
>


Usually, if I'm involved in OS development, I consider an OS not
ready for customers if you can't build it cleanly every night.
That includes development level systems- if changes cause things
to not get built, they shouldn't be integrated.

As being part of doing some development under NetBSD, I did what
I always do- if I see a problem, I fix it. Usually I get thanked.

I didn't understand a couple of things:

1. Integration is very asynchronous, due to the nature
of remote cvs. There will always be some breakage due to this.

2. I still am not in sync with the 'way of doing things' in NetBSD.
I may never be. I should have sent email. Jason has suggested hooking
into a sort of emacs 'talk' window that keeps people more up to
date- sorta like being down the hall, I guess- I personally don't have
the 'direct focus' time to spend on this. As such, I probably shouldn't
just make changes as if I were a primary development team member.

In the future, I'll just wait to see something get fixed, send mail,
or stick to the area of things that I'm supposed to be responsible for.

Sorry for the perturbation.