db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean T. Anderson" <...@bristowhill.com>
Subject Re: New contributors?
Date Thu, 07 Sep 2006 23:46:50 GMT
Daniel John Debrunner wrote:
>Jean T. Anderson wrote:
>>Daniel John Debrunner wrote:
>>>Jean T. Anderson wrote:
>>>
>>>>It might be helpful for reviewers to clearly separate "must fix" items
>>>>from "nice to have" items in their comments.
>>>
>>>Sounds great, but what is a must fix? 
>>
>>A simple definition could be anything that would prevent it from being
>>committed. If a committer doesn't have confidence in a change introduced
>>by the patch, then it should *not* be committed.
> 
> I don't think that's correct. A patch is committed when at one committer
> has the confidence in it, other committer's confidence levels don't
> matter. If others believe the patch should not go in, then they can veto.

I should have said this, which is what I really meant:

A simple definition could be anything that would prevent it from being
committed. If a committer doesn't have confidence in a change introduced
by the patch, then he or she should *not* commit it.

That doesn't preclude the possibility that another committer might veto
the commit.

In other words, as a reviewer state how much you care that a particular
item be fixed.

>>To take a concrete example .....
>>
>>I won't commit a doc patch unless:
>>
>> - Somebody indicates the changes are technically ok.
>> - The DITA doc build succeeds.
>  
> But my (or someone else's) confidence level *might* be lower, if the doc
> builds then it's ok, better to get more eyes on it earlier, thus I
> commit it, even if you don't have confidence.

That's fine -- I view it as an individual committer definition. *I*
(Jean) won't commit a doc patch unless ... [insert the bullets from the
above].  I don't expect others to adopt my criteria.

That much said, I'll be kind of annoyed if somebody does a commit and
the doc build fails.  :-) And only because I know how time consuming it
is to chase down doc build problems.

 -jean

>>But if something isn't worded quite the way I would personally word it,
>>I leave it be -- there's lots of room for style in documentation. Small
>>improvements that advance the info further are good and others can take
>>it even further.
> 
> 
> Right.
> 
> Dan.
> 


Mime
View raw message