Al Hopper wrote:
> On Fri, 1 Jun 2007, Peter Memishian wrote:
> 
>>
>> > >         * A number of places do something like this:
>> > >
>> > >             #
>> > >             # ksh is not lint-clean yet.  Fake up a target.
>> > >             #
>> > >             lint:
>> > >                     @ print "usr/src/cmd/ksh is not lint-clean: 
>> skipping"
>> > >                     @ $(TRUE)
>> > >
>> > >           The above doesn't seem consistent with the way we handle 
>> this
>> > >           elsewhere in ON.  Instead, the general rule is to have a 
>> normal
>> > >           lint target that spews warnings, and simply omit the 
>> directory
>> > >           from $(SRC)/Makefile.lint
>> >
>> > AFAIK (if I remeber this correctly) we tried that and it didn't work 
>> and
>> > then we've copied the solution of the "perl" built - see
>> > 
>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/perl/Makefile#59
>>  
>>
>> > The original "Incomplete Tourist Guide" covered this item - see
>> > 
>> http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-June/000433.html
>>  
>>
>>
>> It mentions it, but I don't see a justification.  We generally only use
>> that for things we know we will never make lint-clean -- and there are
>> only two examples of that which I see in ON (fmli and perl).  Everything
>> else works the way I suggested.
> 
> I don't understand what the "problem" is with the way Roland has 
> implemented this?  Is it a _big_ problem - or is is simply your personal 
> preference?

Beyond everything else, being consistent is good.  That's even more relevant 
to the bits you snipped.

> Please don't ask an unpaid, volunteer, OpenSolaris developer to make 
> changes that are simply stylistic or (personal) preference based. 

Why? That's just as important as anything else.  Especially if taken to its 
"Ignore cstyle, do what you like" extremes.

> Consider that Sun employees are paid to make any changes their 
> management requests - but that simply can't apply to volunteers like 
> Roland who have already put *hundreds* of unpaid man-hours into a project.

Code review is code review.

> If its important to you personally - then please feel perfectly free to 
> checkout the relevant files and make the changes yourself.
> 
> I would like to see the ON integration team work more synergistically 
> with Roland to get ksh93 integrated into ON ASAP.  In many cases, I see 
> emails suggesting changes, where the time it takes to write the bloody 
> email is longer than the time it would take to checkout the source and 
> *make* *the* *suggested* *changes*.  And, AFAIC, this is simply 
> unacceptable behavior.

I don't see a problem with either, frankly.

> Now - please apply the above logic to the rest of this email which I 
> will now .... snip .....
> 
> PS: If its good enough to integrate its *good* *enough* to integrate. We 
> simply can't build GOLD-PLATED software using unpaid OpenSolaris 
> volunteers.

Yeah, I think it's pretty obvious you don't speak for me on this, not even 
close.

-- Rich




Reply via email to