Repository: spark-website Updated Branches: refs/heads/asf-site 0bef76657 -> 4f72689a4
Add a few notes about the relative importance of SQL, core modules, per recent PMC thread Closes #59 Project: http://git-wip-us.apache.org/repos/asf/spark-website/repo Commit: http://git-wip-us.apache.org/repos/asf/spark-website/commit/4f72689a Tree: http://git-wip-us.apache.org/repos/asf/spark-website/tree/4f72689a Diff: http://git-wip-us.apache.org/repos/asf/spark-website/diff/4f72689a Branch: refs/heads/asf-site Commit: 4f72689a4bb4fdbcc2cb06488a948f7536bbc17a Parents: 0bef766 Author: Sean Owen <[email protected]> Authored: Fri Aug 24 16:59:54 2018 -0500 Committer: hyukjinkwon <[email protected]> Committed: Sun Aug 26 17:30:34 2018 +0800 ---------------------------------------------------------------------- committers.md | 4 +++- contributing.md | 7 +++++++ site/committers.html | 4 +++- site/contributing.html | 7 +++++++ 4 files changed, 20 insertions(+), 2 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/spark-website/blob/4f72689a/committers.md ---------------------------------------------------------------------- diff --git a/committers.md b/committers.md index 9bfe5f8..1e2a795 100644 --- a/committers.md +++ b/committers.md @@ -90,7 +90,9 @@ this person. well-tested, and well-designed patches. In addition, they should show sufficient expertise to be able to review patches, including making sure they fit within Spark's engineering practices (testability, documentation, API stability, code style, etc). The committership is collectively -responsible for the software quality and maintainability of Spark. +responsible for the software quality and maintainability of Spark. Note that contributions to +critical parts of Spark, like its core and SQL modules, will be held to a higher standard when +assessing quality. Contributors to these areas will face more review of their changes. 3. Community involvement: Committers should have a constructive and friendly attitude in all community interactions. They should also be active on the dev and user list and help mentor newer contributors and users. In design discussions, committers should maintain a professional http://git-wip-us.apache.org/repos/asf/spark-website/blob/4f72689a/contributing.md ---------------------------------------------------------------------- diff --git a/contributing.md b/contributing.md index 9b964a8..bb26896 100644 --- a/contributing.md +++ b/contributing.md @@ -157,6 +157,10 @@ creating a new one. to suggest a typo fix, but refactoring core scheduling logic requires much more understanding of Spark. Some changes require building up experience first (see above). +It's worth reemphasizing that changes to the core of Spark, or to highly complex and important modules +like SQL and Catalyst, are more difficult to make correctly. They will be subjected to more scrutiny, +and held to a higher standard of review than changes to less critical code. + <h3>MLlib-specific Contribution Guidelines</h3> While a rich set of algorithms is an important goal for MLLib, scaling the project requires @@ -329,6 +333,9 @@ above, fix failures and push new commits which will request the re-test in AppVe Changes can be added by simply pushing more commits to the same branch. - Lively, polite, rapid technical debate is encouraged from everyone in the community. The outcome may be a rejection of the entire change. +- Keep in mind that changes to more critical parts of Spark, like its core and SQL components, will +be subjected to more review, and may require more testing and proof of its correctness than +other changes. - Reviewers can indicate that a change looks suitable for merging with a comment such as: "I think this patch looks good". Spark uses the LGTM convention for indicating the strongest level of technical sign-off on a patch: simply comment with the word "LGTM". It specifically means: "I've http://git-wip-us.apache.org/repos/asf/spark-website/blob/4f72689a/site/committers.html ---------------------------------------------------------------------- diff --git a/site/committers.html b/site/committers.html index 2fbba19..351a3e5 100644 --- a/site/committers.html +++ b/site/committers.html @@ -476,7 +476,9 @@ this person.</li> well-tested, and well-designed patches. In addition, they should show sufficient expertise to be able to review patches, including making sure they fit within Spark’s engineering practices (testability, documentation, API stability, code style, etc). The committership is collectively -responsible for the software quality and maintainability of Spark.</li> +responsible for the software quality and maintainability of Spark. Note that contributions to +critical parts of Spark, like its core and SQL modules, will be held to a higher standard when +assessing quality. Contributors to these areas will face more review of their changes.</li> <li>Community involvement: Committers should have a constructive and friendly attitude in all community interactions. They should also be active on the dev and user list and help mentor newer contributors and users. In design discussions, committers should maintain a professional http://git-wip-us.apache.org/repos/asf/spark-website/blob/4f72689a/site/contributing.html ---------------------------------------------------------------------- diff --git a/site/contributing.html b/site/contributing.html index 9fc45e5..b28d93d 100644 --- a/site/contributing.html +++ b/site/contributing.html @@ -363,6 +363,10 @@ to suggest a typo fix, but refactoring core scheduling logic requires much more Spark. Some changes require building up experience first (see above).</li> </ul> +<p>It’s worth reemphasizing that changes to the core of Spark, or to highly complex and important modules +like SQL and Catalyst, are more difficult to make correctly. They will be subjected to more scrutiny, +and held to a higher standard of review than changes to less critical code.</p> + <h3>MLlib-specific Contribution Guidelines</h3> <p>While a rich set of algorithms is an important goal for MLLib, scaling the project requires @@ -574,6 +578,9 @@ above, fix failures and push new commits which will request the re-test in AppVe Changes can be added by simply pushing more commits to the same branch.</li> <li>Lively, polite, rapid technical debate is encouraged from everyone in the community. The outcome may be a rejection of the entire change.</li> + <li>Keep in mind that changes to more critical parts of Spark, like its core and SQL components, will +be subjected to more review, and may require more testing and proof of its correctness than +other changes.</li> <li>Reviewers can indicate that a change looks suitable for merging with a comment such as: “I think this patch looks good”. Spark uses the LGTM convention for indicating the strongest level of technical sign-off on a patch: simply comment with the word “LGTM”. It specifically means: “I’ve --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
