Contribution Guidelines
Pages 14
- Home
- [deprecated]AS7Mixin
- Code of Conduct
- Contribution Guidelines
- Debian and Ubuntu packaging using git dpm
- How to push a branch to sos git repo on RHEL
- How to Write a Plugin
- How to Write a Policy
- Measuring command run times
- Plugin options
- sos.conf.5
- sosreport.1
- Using git hooks to automate tests
- Using git hooks to automate tests with RHEL
Clone this wiki locally
Submitting Pull requests:
-
Commit messages should be split over multiple lines where necessary and are (with the exception of e.g. long command, log, or other output that should be included verbatim) hard-wrapped at 72 characters.
-
Please write clear commit subjects and messages
-
The subject should make it clear what the patch changes for e.g.:
[archive] Fix TarArchive permission handlingis preferred over:
Fix permission handling -
Commits that affect a single plugin should be tagged with the plugin name in brackets in the subject line, for e.g.:
[networking] Add NetworkManager nmcli support -
Include any issues the code fixes (e.g. Closes: #1) on a separate line
-
If working around python or other external behavior describe this in the full commit message for e.g.:
-
commit 6501013bb780161e941f5e078a6ed7052f670a51
Author: Bryn M. Reeves <bmr@redhat.com>
Date: Mon Jun 2 15:27:10 2014 +0100
Make sure grub password regex handles all cases
The regex to match passwords in grub.conf needs to handle both
the --md5 and non-md5 cases and to apply the substitution only
to the secret part (password or password hash).
This needs to deal with the fact that python will return 'None'
for unmatched pattern groups leading to an exception in re.subn()
if not all referenced groups match for a given string (in contrast
to e.g. the perl approach of treating these groups as the empty
string).
Make this explicit by using an empty alternate in the possibly
unmatched '--md5' group:
r"(password\s*)(--md5\s*|\s*)(.*)",
r"\1\2********"
Signed-off-by: Bryn M. Reeves <bmr@redhat.com>
- Each developer should fork sosreport into their accounts repository.
- Not required, but advisable to use feature/patch branches when working with new code.
- All pull requests should be against master branch
- We avoid merge commits in master so branches may need to be rebased over the master-du-jour prior to merging
- All unit tests must pass before the pull request is accepted.
- Testing for sos is automated - a Travis build is run for each pull request.
- To save time developers can enable local git test hooks
- All commits must be accompanied by a
Signed-off-by: Firstname Lastname <email@example.com>-
<email at example dot com>and other obfuscations are fine too. - Use
git commit -sto automatically add a Signed-off-by with your configured git user details.
-
- Make sure you are following pep8 style guidelines
Optional but very helpful
- An sosreport archive generated using the changed code
- Any functional tests we should be aware of in order to verify the pull requests.
- Where possible a test case for the in-tree nosetest suite
- See the existing cases in
tests/for examples
- See the existing cases in
Maintainers
The sosreport team follows a 2 person review process. When a pull request comes in it will be assigned reviewers from the sosreport team. Both reviewers must approve the pull request before a merge can take place.
The previous usage of the labels Needs Second ACK and ACK ready for merge will be deprecated in favor of using GitHub's builtin review functionality. The additional labels such as Needs DCO will continue to be used to provide additional context to the pull requests.