[
https://issues.apache.org/jira/browse/HADOOP-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758515#action_12758515
]
Tsz Wo (Nicholas), SZE commented on HADOOP-6278:
------------------------------------------------
> Do you think a broken build should stop further commits?
Ideally, yes. But it may slow down our development.
> Do you think a broken build is the highest priority for the community to fix?
Definitely yes, especially for the one who has "contributed" to the broken
build.
> Do you think flaky unit tests should be pulled out or put into a separate
> 'category'?
I think the correct approach is to revert the committed patch which breaks the
build. However, this may be hard when the patch has got in for a long time.
How about we set a time limit, say a week, for fixing the build?
> Update HowToCommit with clear list of Committer responsibilities
> ----------------------------------------------------------------
>
> Key: HADOOP-6278
> URL: https://issues.apache.org/jira/browse/HADOOP-6278
> Project: Hadoop Common
> Issue Type: Improvement
> Components: documentation
> Affects Versions: site
> Reporter: Nigel Daley
> Priority: Critical
>
> http://wiki.apache.org/hadoop/HowToCommit should be updated to clearly spell
> out these committer responsibilities:
> 1) For non-trivial patches, code reviews must be done by another *committer*.
> 2) Code reviews follow the checklist
> (http://wiki.apache.org/hadoop/CodeReviewChecklist) so that, among other
> things, the patch is checked for robust documentation and unit tests
> 3) A -1 from Hadoop QA for lack of unit tests *must* be explained
> satisfactorily by the contributor else the patch *is not* committed. In this
> case, the manual tests performed by the contributor must be explained.
> 4) A -1 from Hadoop QA for findbugs, javadoc, or javac warnings means the
> patch *must not* be committed until these are fixed (else every subsequent
> patch will get -1 on these)
> 5) A -1 from Hadoop QA for core *and* contrib unit tests means the patch
> *must not* be committed until these are fixed (else every subsequent patch
> will get -1 on these)
> Others responsibilities?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
