fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <markus.ge...@live.de>
Subject Re: [DISCUSS] Git procedure and branching model
Date Thu, 24 Dec 2015 20:19:47 GMT


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/alternative (inline, None, 0 bytes)
View raw message