You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Nigel Daley (JIRA)" <ji...@apache.org> on 2009/09/23 00:32:16 UTC
[jira] Created: (HADOOP-6278) Update HowToCommit with clear list of
Committer responsibilities
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.
[jira] Commented: (HADOOP-6278) Update HowToCommit with clear list
of Committer responsibilities
Posted by "Tsz Wo (Nicholas), SZE (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (HADOOP-6278) Update HowToCommit with clear list
of Committer responsibilities
Posted by "Jakob Homan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758465#action_12758465 ]
Jakob Homan commented on HADOOP-6278:
-------------------------------------
Now that the project has split, should this include generating and promoting updated jars up the dependency line? That's not always getting done.
> 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.
[jira] Commented: (HADOOP-6278) Update HowToCommit with clear list
of Committer responsibilities
Posted by "Tsz Wo (Nicholas), SZE (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758467#action_12758467 ]
Tsz Wo (Nicholas), SZE commented on HADOOP-6278:
------------------------------------------------
Sounds great! Some questions:
> 1) For non-trivial patches, code reviews must be done by another committer.
Does it mean that non-committers can review trivial patches? Then, does a committer require to review the trivial patch when committing it?
BTW, it may be hard to decide whether a patch is trivial or not.
> 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)
What if an existing unit test fails, which is not related to the patch? An example is TestBackupNode (HDFS-192), which keeps failing in 6 months.
> 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.
[jira] Commented: (HADOOP-6278) Update HowToCommit with clear list
of Committer responsibilities
Posted by "Nigel Daley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758502#action_12758502 ]
Nigel Daley commented on HADOOP-6278:
-------------------------------------
Nicholas, you're correct, 1 should be:
1) For all patches, code reviews must be done by another committer.
For number 5, what do you suggest? Do you think a broken build should stop further commits? Do you think a broken build is the highest priority for the community to fix? Do you think flaky unit tests should be pulled out or put into a separate 'category'?
> 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.