Hello,
Gruno says that in order to graduate we need a "merge to master/ policy." He
used a different term, but I forget what he called it. In essence, every merge
to master/ (or a release branch -- e.g. tp30) requires a VOTE where committers
(not just PMC) have bindings votes.
I suggest we start doing this post 3.0.2 release. Right now its too much to ask
with Stephen preparing the tp30/ release and branches getting merged
accordingly.
How would this look?
1. When you do work, it should reflect a JIRA ticket.
- Thus, make a branch/ called TINKERPOP3-XXX which is the JIRA
ticket number.
2. Be sure to always merge master/ into your branch so it doesn't get
stale and difficult to merge back.
3. When you are done with your work, present it to dev@ with a [VOTE].
- Provide links to your branch, your ticket, and a summary of
what you accomplished.
- Be sure your branch includes CHANGELOG, docs, etc. update as
there is a full circle here -- not just, "I fixed bug."
4. If the VOTE passes then you can merge it to master.
- MENTOR: Gruno, please specify the rules for passing "code
votes."
I think we can make exceptions to this rule for the following situations:
1. On "release day" the person handling the release will need to "push"
a bunch cause of version stamping, URL updating, etc. That "push"-sequence
doesn't require VOTE.
2. When the release is finally complete the person handling the release
will need to bump the version to the next SNAPSHOT. That "push"-sequence
doesn't require VOTE.
3. ???
Thoughts?,
Marko.
http://markorodriguez.com
