fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: [DISCUSS] Git procedure and branching model
Date Thu, 24 Dec 2015 17:02:46 GMT
On Thu, Dec 24, 2015 at 2:34 AM, Markus GeiƟ <markus.geiss@live.de> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message