svn commit: r185499 - head

[Garrett Cooper]

On Thu, Dec 4, 2008 at 11:48 AM, Alfred Perlstein <alfred at freebsd.org> wrote:
> * Dag-Erling Sm??rgrav <des at des.no> [081204 10:21] wrote:
>> Alfred Perlstein <alfred at freebsd.org> writes:
>> > No, I'm trying to get a simple target that makes sense that will
>> > prevent people from breaking tinderbox.  (failing that then turning
>> > tinderbox off because it's too complex)
>>
>> Perhaps if you tell me what it is about the tinderbox that you don't
>> understand, I could help you understand it.
>
> I think I have all I need right now.  I was getting confused
> because I was being told by multiple confused developers that
> "tinderbox" was different things because it's complicated.
>
> We should probably review all these committers and paddle them
> or yank their commit bits for being stupid or something.
>
>> > Lets just say it takes a developer about an hour or two to be
>> > "enlightened" as to a new system instead of just being told "hey
>> > run this one liner", you've just soaked up $number_of_committers *
>> > $enlightenment_time man hours.
>>
>> What is new about the build system?  And why do you think it's a bad
>> idea for committers to understand how it works?  Do you really want to
>> run an operating system written by people who do not understand how it
>> is built?
>
> It should not be a requirement that a developer need to know
> all this stuff.  And by stuff I mean "how to roll my own tinderbox".
>
> I do find it amusing that you're asserting that _I'm_ saying this
> when I'm the only one it appears that could fix this target. :)
>
> I'm more concerned about developing anything where I have to work
> with people that don't take input on issues, yell at people for not
> understanding complex systems and winge for god knows how long about
> a 20 line patch just because it wasn't exactly "how they would have
> done it"... WHEN IN FACT THEY REFUSED AND WOULD NOT HAVE "DONE IT".
>
>> > That and, since the process requires "enlightenment", you've caused
>> > that developer to "page out" whatever they had in their head to work
>> > on, _every time they commit_.  Soooooo frustrating.
>>
>> I wonder - does anybody else than you have that problem?  Don't you
>> think that once people understand how the build system works, they would
>> be able to do this without much thought?  As a bonus, they will also
>> know how to rebuild just the parts they modified, instead of the entire
>> tree, shaving hours off the edit-compile-test cycle.
>
> Yes, that's great, but it should be optional.  We shouldn't beat
> things into people.
>
>> > And I'm done too!
>>
>> But in the process, you managed to piss off just about everybody who had
>> an interest in the matter.
>
> That was your choice.  So far I'm not aware of anyone that's quit
> freebsd in the past few years due to anything I've done.
>
> (really done now) :)
>
> --
> - Alfred Perlstein

Don't mean to stir up the hornet's nest any further, but I wanted to
help constructively with this `issue':

1. I can see the logic behind what Alfred's doing, and I agree with it
100% with the following `terms':
   a. For generic kernel / userland codebase changes, a `tinderbox'
target like Alfred put in, would be best for determining issues over
the entire system.
   b. For codebase changes that are target/arch specific or contain
target-specific driver code (for instance a MIPS specific net driver),
it wouldn't really make sense to run Alfred's tinderbox for
everything.
   c. For commit and after a merge, Alfred's `tinderbox' target should
be executed.
2. I honestly think that the tinderbox target should be renamed to
tinderfarm though, because I see the argument that DES is noting,
mostly because of continuity. I do think that keeping a tinderfarm
build target within the make system would be beneficial though, as it
would allow the tinderbox Perl script to shrink and DES and I would be
able to work out an agreement for making a tinderbox (/ tinderfarm?)
script to be used as an overall functional and regression testing
framework.
3. Devs understanding how the build system works to the extent where
they can dig up manpages and become more proficient if necessary is
crucial. I've seen some very negative effects of using wrapper scripts
to execute builds, and I'd rather we not go this route, if at all
possible. However, having a more abbreviated way of expressing builds
is nice though, because most folks maintain this logic in wrapper
scripts in local workspaces, and this information quickly gets out of
date as time progresses :).
3. As for the issue with make universe, isn't there an equivalent to
:: in pmake like there is in gmake? Targets can fail to build, but at
least it'll continue moving on, and if the output messages are proper,
one can note: `blah target failed' *shrugs*, and keep on moving on.
Most devs should be using a break on build error make mode, whereas
overall tinderfarm executions on the freebsd project servers shouldn't
fail, IMHO.

Thoughts?
-Garrett