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 15:35:45 GMT
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
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message