fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Geiss <markus.ge...@live.de>
Subject Re: [DISCUSS] Git procedure and branching model
Date Tue, 29 Dec 2015 16:12:19 GMT
Looks like attachments won't work, so let me try to explain in
words. ; o)

We use the branch develop for ongoing new feature, enhancements,
and bug fixe development. Aside from really small changes
(like a typo), a developer/contributor creates a feature branch
for his development effort. Once he is done with his work, he
prepares and sends a Pull Request.

A committer is doing a review of the changes, and if necessary,
comments on the Pull Request suggestion some changes. Once the
Pull Request is in line with our code conventions, the committer
pulls this changes into the 'real' repo, is running a build to
assure tests won't fail, and commits them. No need for any
voting, he has earned the right to do so, and this is good.

If a release is to be made, the self-appointed Release Manager
creates a new branch from develop, named after the release, and
assures that all tests are running, all needed documentation is
in place, and the ASF policies are fulfilled. During this period,
the ongoing development can happen as described above, no need
to stop others on working for the project. During this phase, it
is feasible and sometimes needed to pull bug fixes, or additional
features from the develop branch into the release, that's fine.

Best,

Markus

.::YAGNI likes a DRY KISS::.

On 12/29/2015 04:35 PM, Markus Geiss wrote:
> Sometimes an image is worth a thousand words. Please find attached two
> images that visualize the workflow I was talking about. The workflows
> are not on a detail level, they simply provide an overview.
>
> Best,
>
> Markus
>
> .::YAGNI likes a DRY KISS::.
>
> On 12/29/2015 04:11 PM, Markus Geiss wrote:
>> I think we're talking about the same thing here.
>>
>> Just one exception, I'd suggest a code review based on agreed coding
>> standards to keep the code clean and in line with what is needed.
>>
>> I see a difference between a committer, who has the right to pull in
>> changes directly, without an agreement by others because he 'earned' the
>> right too do so, and a contributor. For me a contributor is somebody who
>> is on the path to become a committer if she/he earns the merit. A code
>> review based on a pull request will assure this and keep our code at a
>> high quality. I think merging 'foreign' changes without looking at them
>> is dangerous.
>>
>> Maybe we need to clarify the terms we use and the role they play, we
>> already had some hazzle based on misunderstood terms, I refer to the
>> following explanations:
>>
>> Contributor =
>> http://www.apache.org/foundation/how-it-works.html#developers as
>> mentioned there also know as contributor
>>
>> Committer = http://www.apache.org/foundation/how-it-works.html#committers
>>
>> Best,
>>
>> Markus
>>
>> .::YAGNI likes a DRY KISS::.
>>
>> On 12/29/2015 03:58 PM, Greg Stein wrote:
>>> I'm not sure if I'm reading Markus' post correctly, so let me throw out
>>> some specific commentary...
>>>
>>> CTR implies that any committer can push any change, any time.
>>> Unilaterally,
>>> without prior consent. That change can come from a pull request, or it
>>> can
>>> arrive from original work. Doesn't matter. A committer can push changes.
>>> Period.
>>>
>>> Second part: a branch to prepare a release, with more constraints on
>>> commits (Markus said "prevent unwanted commits"). ... My view, from
>>> Apache
>>> land, is that a Release Manager (RM) is self-appointed. Anybody can be a
>>> release manager, and can do the work to prepare a release (the only
>>> trouble
>>> arrives when multiple RMs arrive and try to claim the name/version for
>>> the
>>> next release; doesn't happen). So the RM *creates* a branch to prepare
>>> the
>>> release. That is *their* branch. They get to define the rules. They
>>> get to
>>> "prevent unwanted commits". ... I recommend a STATUS file where people
>>> can
>>> decide on changes to cherry-pick into that release. ... but that branch
>>> clearly sits outside the project's normal CTR process.
>>>
>>> While a release is being prepared, the main line remains open as CTR.
>>> Please, never allow distrust to creep into commits against
>>> master/develop.
>>>
>>> Cheers,
>>> -g
>>>
>>>
>>> On Tue, Dec 29, 2015 at 2:47 AM, Markus Geiss <markus.geiss@live.de>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>> Best,
>>>>
>>>> Markus
>>>>
>>>> .::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Ɵ [mailto:markus.geiss@live.de]
>>>>> Sent: 25 December 2015 20:51
>>>>> To: dev@fineract.incubator.apache.org
>>>>> 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:
>>>>> http://www.apache.org/foundation/voting.html#LazyConsensus ... a
>>>>> similar
>>>>> sentence can be found here too:
>>>>> http://www.apache.org/foundation/glossary.html#LazyConsensus ... (and
>>>>> even
>>>>> http://community.apache.org/committers/lazyConsensus.html 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: gstein@gmail.com
>>>>>> To: dev@fineract.incubator.apache.org
>>>>>>
>>>>>> Which doc? I need to fix it :-)
>>>>>>
>>>>>> On Thu, Dec 24, 2015 at 2:19 PM, <markus.geiss@live.de> 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" <
>>>>>>> roman@shaposhnik.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Dec 24, 2015 at 9:02 AM, Greg Stein <gstein@gmail.com>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>

Mime
View raw message