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