fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adi Raju" <adi.r...@confluxtechnologies.com>
Subject RE: [DISCUSS] Git procedure and branching model
Date Tue, 29 Dec 2015 08:29:15 GMT
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