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. >
