New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes #303
8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes #303
Conversation
…eatures plus Skara changes
👋 Welcome back kcr! A progress list of the required criteria for merging this PR into |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additional comments:
- "Use Unix-style (LF) line endings not DOS-style (CRLF)" needs a comma before "not".
- "Line width is no more than 120 characters" I remember that it was 130 or 135 somewhere.
- "Wildcard imports (import foo.bar.baz.*) are forbidden" Junit imports use them extensively.
./gradlew all test
will cause failure on webkit tests if it was not built.
Webrevs
|
Regarding your additional comments:
Fixed.
You're probably remembering an old version, but it's been 120 for a while now.
Fixed to add an exception for wildcard static imports in tests.
Added a note about this and a pointer to the Web Testing doc. |
/reviewers 2 |
@kevinrushforth |
The "New features / API additions" repeats some things already stated. Is it to make each section independent? |
I wanted the "New features / API additions" section to stand on its own. Once thing that might be redundant now is the following sentence in the "Contributing code and documentation changes" section: "Feature requests, in particular, must be discussed ahead of time and will require significant effort on your part." I think that could be removed or incorporated in "New features / API additions". |
I think that "Contributing to the OpenJFX codebase" should be renamed to something related to a style guide. Then split the testing part to its own subsection. Also, I still find it confusing that "New features / API additions" is not under the code contribution section. There seems to be 2 main sections: reporting bugs / requesting features - these don't involve code, just talk; then there is contributing code, which covers the process for setup, submissions of bugs fixes, submission of features/API, style, and testing (in some order). Wouldn't this be a better flow? |
Yes, I do think the flow could be better. I'll need to put this on hold for a while, but when I get back to it, I'll look at your suggestions and see if I can come up with something that will improve the flow. Btw, the thinking behind putting the "New features / API additions" sections at the end (sort of like an appendix) is that I didn't want it to get in the way of the "here's how you sumbit and review a PR" for bug fixes, which is the more common case. I don't think it achieves that in its current form. |
not sure whether it belongs here, or whether or not it's obviously implied but: I would like to see a bit of clarification on testing of contributions. Right now the sentence might be interpreted to be about running available tests:
add something like:
|
Is there any plan to integrate this? I quite like the change and it makes the process much more clear. :) |
Yes, I'll pick this back up soon. |
This has been dormant for a long time, so I just merged the latest master. I also discovered a couple additional changes I had in a "working" branch that I will push to address a couple minor comments. I still need to get back to this to address the comments from @nlisker about the flow, so that might take a bit more time, but I would like to get this moving to at least fix the fact that several things are wrong or misleading in the current doc. |
…, but forgot to push
1. Renamed "Contributing to...codebase" section to "Coding style and testing guidelines", and switched that section with the "New features section" 2. Updated recommend JDK 3. Added forward reference for Draft and WIP PRs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR is a major improvement over the existing status.
I therefore recommend to integrate this, and have other issues being discussed in follow-up issues. A contributing guideline document is a moving target.
I will review this shortly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added 1 suggestion.
@kevinrushforth This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 1 new commit pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the ➡️ To integrate this PR with the above commit message to the |
/integrate |
@kevinrushforth Pushed as commit 18063ad. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
This PR updates the
CONTRIBUTING.md
guide to address the following:Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jfx pull/303/head:pull/303
$ git checkout pull/303
Update a local copy of the PR:
$ git checkout pull/303
$ git pull https://git.openjdk.java.net/jfx pull/303/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 303
View PR using the GUI difftool:
$ git pr show -t 303
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jfx/pull/303.diff