Greg makes some good points below. At least one of which is a fundamental part of doing things the Apache Way. That is don't vote, use lazy consensus. Since this is so important to a successful Apache project it's worth expanding on this a little. See http://community.apache.org/committers/lazyConsensus.html
-----Original Message----- From: Greg Stein [mailto:[email protected]] Sent: Thursday, December 24, 2015 5:03 PM To: [email protected] Subject: Re: [DISCUSS] Git procedure and branching model On Thu, Dec 24, 2015 at 2:34 AM, Markus Geiß <[email protected]> wrote: >... > I suggest the following branching model: > > - we adopt the Forking Workflow[1] as the core principal, and > The ASF doesn't create personal repositories, so the Forking Workflow isn't available. I'd recommend just using branches within the main repo. > - adopt the Gitflow Workflow[2] for ongoing development. > +1 > Feature branches should be created using the name of the JIRA issue > which is to be solved. > If you discuss a feature on the dev@ list, then why create a JIRA issue? The community already knows a feature is going to be developed. No need to create an issue for it. Or if somebody wants to experiment with an issue, they can create that issue on a branch and then ask the community to take a look. There isn't a need to *track* new features. JIRA is for tracking the resolution of *problems*. Features are simply written. Meta: JIRA is busy-work, if used for features. > As our version scheme I'd suggest Semantic Versioning[3]. > +1 > > This would lead to the following branches: > > - master > - hotfix > - develop > - v1.0.0 > - FINERACT-[#] > > Given the way the Apache framework is working[4], we need to find > consensus on how to deal with code modifications and releases. Aside > from discussing major changes prior to implementation, some kind of > voting is needed. > Try to avoid voting at all costs. Assume lazy consensus everywhere. ... voting creates losers. > I suggest to use the CTR[5] (commit then review) model for code > modifications, and RTC[6] (review then commit) for package releases. > We should not mismatch review with a code review. A code review should > be done based on the pull request and prior to commit the changes into > the main repository. Once this process has finished, a vote based on > lazy consensus is initiated with a message like "This solves issue > FINERACT-1234, if no-one objects within three days, I'll assume lazy > consensus and commit it." > That is not CTR. Commit straight away. Don't wait. "This looks good to me. <commit>" You use the term "object", but that isn't quite right. Commit the change. Others can review. If they have *issues* with the change, then you begin a discussion. Not an objection. The goal is to *fix* what was committed. Not to object to it, and roll it back. When the commit lands in the repository, then review happens (CTR). And based on the review, further changes can be applied. Remember: this is version control. There is no reason to "object". There is no reason to vote. Everything goes into version control with the lowest barrier possible. Let people directly commit to a branch, or even to the "develop" main branch. Why not? If it breaks something, then fix it. Worst case, it can always be backed out. TRUST each other to commit working code, and fixes, and new features. Trust is a huge issue. Please don't erect barriers. Please don't control the repository via JIRA. Let people write and commit code. Give them room, and let them work. Contributions are *always* a bonus, and very rarely a harm. So optimize for the former. Cheers, -g
