fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Geiss <>
Subject Re: [DISCUSS] Git procedure and branching model
Date Tue, 29 Dec 2015 08:47:34 GMT
My suggestion implies some prior steps to commit a change.

If we use the forking model (via the mirror) a pull request will be 
reviewed prior to the merge into the Apache Git Repo.

If we call a release we will create a new branch for it, e.g. v1.0.0. 
This will prevent unwanted commits to fly in the release, but allows the 
ongoing development to proceed. The release branch will be reviewed 
prior to voting, so we can validate its functionality.

Hope this clarifies my suggestion.



.::YAGNI likes a DRY KISS::.

On 12/29/2015 09:29 AM, Adi Raju wrote:
> Need some more clarity.
> If we use CTR, how do we control the release timelines. I mean, if we get a
> commit at the last minute or commits with partial fix/regressions, wouldn't
> this create issues with release timeline?
> Am I right to assume, release RTC process starts X days before planned
> release date, so that issues identified can be fixed?
> Do we allow releases to be made with known bugs?
> Regards,
> Adi
> -----Original Message-----
> From: Markus GeiƟ []
> Sent: 25 December 2015 20:51
> To:
> Subject: RE: [DISCUSS] Git procedure and branching model
>> The ASF doesn't create personal repositories, so the Forking Workflow
>> isn't available. I'd recommend just using branches within the main repo.
> Just to be clear, I was talking about the general approach for
> contributions, I guess the usual way is to fork the mirror and send pull
> requests ... the 'real' git repo is handled in a different.
> It's good that we agree on the Gitflow branching model, though.
>> Which doc? I need to fix it :-)
> Here you'll find the blue print for the email:
> ... a similar
> sentence can be found here too:
> ... (and even
> states 'express
> support or objections') ; o)
> Best,
> Markus
> .::YAGNI likes a DRY KISS::.
>> Date: Thu, 24 Dec 2015 17:03:22 -0600
>> Subject: Re: [DISCUSS] Git procedure and branching model
>> From:
>> To:
>> Which doc? I need to fix it :-)
>> On Thu, Dec 24, 2015 at 2:19 PM, <> wrote:
>>> thanks for the feedback ... I think jira issues are simply a good
>>> way of organizing work ... you see what is going on w/out reading a
>>> bunch email threads.
>>> The sample commit message I've used was directly copied from the ASF
>>> documentation ... but I'm fine doing a commit instead of pre calling
>>> it out that makes totally more sense to me.
>>> Cheers
>>> Markus
>>> ::: YAGNI likes a DRY KISS :::
>>> On Thu, Dec 24, 2015 at 11:54 AM -0800, "Roman Shaposhnik" <
>>>> wrote:
>>> On Thu, Dec 24, 2015 at 9:02 AM, Greg Stein <> wrote:
>>>>> 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.
>>> I disagree. I find JIRA a much more flexible tool for tracking on
>>> going work on the project. JIRA allows me things like registering
>>> for notifications, integration with GH pull requests, etc. that are
>>> simply too tedious to do using pure mailing list workflow.
>>> Now, I agree with you that fixing a one liner probably shouldn't
>>> require JIRA -- everything else just use JIRA as your community TODO
>>> list.
>>> In fact, enter *ideas* into JIRA, keep things marked for newbies, etc.
> etc.
>>> This is, again, where JIRA shines over mailing list -- if somebody
>>> new comes to the community and asks how she or he can help -- it is
>>> much easier to point a JIRA query that would give you exact list of
>>> issues than a pointer to mailing list discussions or wiki.
>>>> Meta: JIRA is busy-work, if used for features.
>>> Not always. I fine it useful, for example, to track evolution of a
>>> proposals or blueprints. And yes, certain feaatures will require
>>> those documents to get buy-in from the community.
>>>>> 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.
>>> Huge +1 to the above!
>>> Thanks,
>>> Roman.

View raw message