THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
You will not have write permission to github apache mirror, you need to
fork https://github.com/apache/incubator-netbeans to your own repositories.
You need to clone the forked repository and setup name and mail. This also may help git rebase to fullfil fulfill its task.
git config --global user.name "John Doe"
git config --global user.email "john@doe.org"
...
- All commits must include the authors full name and email address.
- All new files must include the Apache Software Foundation license header. See any NetBeans source code in case of doubt.
- All commits must contain a meaningful commit message.
- A meaningful commit message holds in the first line a summary of the commit and in the body (beginning on the third-line) an explanation what was changed and why it was done.
- Remember that the future this commit message is most probably the only source of information why a change was committed to the code base.
- If the commit fixes a reported issue, the summary line should hold the issue number and title
"[NETBEANS-XXX] Maven pom.xml file corrupted after inserting dependecies"
for example.
- A Pull Request can consist of multiple commits. These commits should group the changes into meaningful entities. Fixup commits should be squashed into the base commit they fix.
- For contributors: Be prepared to be asked questions about your PR.
- A reviewer might have questions and you should be able to answer why you did a fix in a certain way and why it is safe and appropriate.
- Remember that the review sometimes takes as long, as creating a patch in the first place.
- Good commit messages help as they anticipate questions.
- For reviewers: Keep in mind that the contributor wants to fix a problem and put effort into it. So be polite and focused.
- Don't change code that is correct and works.
- Consider a simple loop. In many cases you can switch between for-loop, for-each-loop and stream construct. All are valid solution, don't change the code if it is not broken.
- An improvement is a different case. For example a try-with-resource construct is in general more correct, than the try-finally construct many developers fail to implement correctly.
- Constructs leading to warnings from the
javac
are also good candidates for simple fixes.
- Run unit tests and, if you introduce new feature/fixes, add unit tests. So before you start your work, check that unit tests for the module you are working on run correctly and after you are done still do.
- If unit tests fail, fixing these would be good addition to the code base (it would be good to use a separate commit for this)
- Keep your pull requests up-to-date. When the PR can't be merged directly /it can happen that changes are introduced into the code base, that conflict with your PR,) you should then update it accordingly.
- Follow the coding conventions of the file. Your code should match that style and not stand out. For new files, please follow the code conventions for the NetBeans code base: https://netbeans.org/community/guidelines/code-conventions.html
- Try to keep the code readable, maintainable, easy to debug and performant.
...