*We would like to make it easier for community members to submit pull
requests, even if it makes our jobs a little harder. Contributors should
target their changes at the master branch. This is already called out in
the CONTRIBUTING.md. It falls on the committers to port the change to the
correct branch to receive those changes.
We have an abundance of pages that try to describe how the development
process works. These mostly agree with each other, but often duplicate and
have slight variations of the information. Our goal is to consolidate this
information and make it very clear how contributions get into the codebase,
so that we can start removing the barriers to opening up the repo to more
community committers.
We are thinking that the following information might be best kept inside a
COMMITTERS.md document in the project:
- Guidelines for what releases should get patched.
- The latest minor release of a major release. Older minor releases
in a major release do not get patched. Because of the change to semver,
thinking about this has not been an issue before. This is a new
policy that
is there to limit the number of active releases that need to be
dealt with.
- Security patches are handled differently.
- Guidelines for how to merge patches into different releases (e.g. 2.7
is patched, how do we get the change into 3.0?).
- merge up through all later branches by using “--no-ff --log”
- When a new minor release branch is created (e.g. 3.1.x) then the
previous one is deleted (e.g. 3.0.x). Any security or urgent fixes that
might have to be applied to the older code line is done by creating an
ad-hoc branch off of the tag of the last patch release of the old minor
line.
- The currently supported branches (this ties into the first point).
- A checklist of items to look for during a code review.
- All tests pass
- Any platform gotchas? (Windows, Solaris, etc.)
- Backwards compatible?
- YARD docs for API?
- Any need for documentation changes? If so how will they be handled?
- Clean code
- Changes conform to the contributing guide
- Guidelines for being a good commit citizen by watching the automated
build
- Don’t push on a broken build
- Watch the build until your changes have gone through green
- Update the ticket status and target version
- Ensure the pull request is closed
This would allow us to:
1. have current guidelines about how far back to apply patches
2. consolidate "current" information
3. Kill
http://projects.puppetlabs.com/projects/puppet/wiki/Engineering_Process_Minimal_HOWTO.
4. Kill
http://projects.puppetlabs.com/projects/puppet/wiki/Puppet_Design_Guidelines
5. Kill
http://projects.puppetlabs.com/projects/puppet/wiki/Internal_Development_Process
Kill
http://projects.puppetlabs.com/projects/puppet/wiki/Engineering_done_done*
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
