Return-Path: X-Original-To: apmail-fineract-dev-archive@minotaur.apache.org Delivered-To: apmail-fineract-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 19FED180F1 for ; Tue, 29 Dec 2015 16:12:40 +0000 (UTC) Received: (qmail 18508 invoked by uid 500); 29 Dec 2015 16:12:40 -0000 Delivered-To: apmail-fineract-dev-archive@fineract.apache.org Received: (qmail 18489 invoked by uid 500); 29 Dec 2015 16:12:40 -0000 Mailing-List: contact dev-help@fineract.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@fineract.incubator.apache.org Delivered-To: mailing list dev@fineract.incubator.apache.org Received: (qmail 18478 invoked by uid 99); 29 Dec 2015 16:12:39 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Dec 2015 16:12:39 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 51616C0D4D for ; Tue, 29 Dec 2015 16:12:39 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=6.31 tests=[SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 6fCr-ph_dsoT for ; Tue, 29 Dec 2015 16:12:31 +0000 (UTC) Received: from BLU004-OMC2S34.hotmail.com (blu004-omc2s34.hotmail.com [65.55.111.109]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id EBEA820532 for ; Tue, 29 Dec 2015 16:12:30 +0000 (UTC) Received: from BLU436-SMTP53 ([65.55.111.72]) by BLU004-OMC2S34.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 29 Dec 2015 08:12:24 -0800 X-TMN: [YDxEZJS4NTPNYd8tDDiba/j1PievP4wE] X-Originating-Email: [markus.geiss@live.de] Message-ID: Subject: Re: [DISCUSS] Git procedure and branching model References: <014601d14213$027b1e50$07715af0$@confluxtechnologies.com> To: dev@fineract.incubator.apache.org From: Markus Geiss Date: Tue, 29 Dec 2015 17:12:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 29 Dec 2015 16:12:21.0924 (UTC) FILETIME=[B2C21E40:01D14253] Looks like attachments won't work=2C so let me try to explain in words. =3B o) We use the branch develop for ongoing new feature=2C enhancements=2C and bug fixe development. Aside from really small changes (like a typo)=2C a developer/contributor creates a feature branch for his development effort. Once he is done with his work=2C he prepares and sends a Pull Request. A committer is doing a review of the changes=2C and if necessary=2C comments on the Pull Request suggestion some changes. Once the Pull Request is in line with our code conventions=2C the committer pulls this changes into the 'real' repo=2C is running a build to assure tests won't fail=2C and commits them. No need for any voting=2C he has earned the right to do so=2C and this is good. If a release is to be made=2C the self-appointed Release Manager creates a new branch from develop=2C named after the release=2C and assures that all tests are running=2C all needed documentation is in place=2C and the ASF policies are fulfilled. During this period=2C the ongoing development can happen as described above=2C no need to stop others on working for the project. During this phase=2C it is feasible and sometimes needed to pull bug fixes=2C or additional features from the develop branch into the release=2C that's fine. Best=2C Markus .::YAGNI likes a DRY KISS::. On 12/29/2015 04:35 PM=2C 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=2C they simply provide an overview. > > Best=2C > > Markus > > .::YAGNI likes a DRY KISS::. > > On 12/29/2015 04:11 PM=2C Markus Geiss wrote: >> I think we're talking about the same thing here. >> >> Just one exception=2C 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=2C who has the right to pull in >> changes directly=2C without an agreement by others because he 'earned' t= he >> right too do so=2C and a contributor. For me a contributor is somebody w= ho >> 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=2C we >> already had some hazzle based on misunderstood terms=2C I refer to the >> following explanations: >> >> Contributor =3D >> http://www.apache.org/foundation/how-it-works.html#developers as >> mentioned there also know as contributor >> >> Committer =3D http://www.apache.org/foundation/how-it-works.html#committ= ers >> >> Best=2C >> >> Markus >> >> .::YAGNI likes a DRY KISS::. >> >> On 12/29/2015 03:58 PM=2C Greg Stein wrote: >>> I'm not sure if I'm reading Markus' post correctly=2C so let me throw o= ut >>> some specific commentary... >>> >>> CTR implies that any committer can push any change=2C any time. >>> Unilaterally=2C >>> without prior consent. That change can come from a pull request=2C or i= t >>> can >>> arrive from original work. Doesn't matter. A committer can push changes= . >>> Period. >>> >>> Second part: a branch to prepare a release=2C with more constraints on >>> commits (Markus said "prevent unwanted commits"). ... My view=2C from >>> Apache >>> land=2C is that a Release Manager (RM) is self-appointed. Anybody can b= e a >>> release manager=2C 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=3B doesn't happen). So the RM *creates* a branch to prepar= e >>> 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=2C the main line remains open as CTR. >>> Please=2C never allow distrust to creep into commits against >>> master/develop. >>> >>> Cheers=2C >>> -g >>> >>> >>> On Tue=2C Dec 29=2C 2015 at 2:47 AM=2C Markus Geiss >>> 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=2C e.g. v1.0.0= . >>>> This >>>> will prevent unwanted commits to fly in the release=2C but allows the >>>> ongoing >>>> development to proceed. The release branch will be reviewed prior to >>>> voting=2C so we can validate its functionality. >>>> >>>> Hope this clarifies my suggestion. >>>> >>>> Best=2C >>>> >>>> Markus >>>> >>>> .::YAGNI likes a DRY KISS::. >>>> >>>> On 12/29/2015 09:29 AM=2C Adi Raju wrote: >>>> >>>>> Need some more clarity. >>>>> If we use CTR=2C how do we control the release timelines. I mean=2C i= f >>>>> we get >>>>> a >>>>> commit at the last minute or commits with partial fix/regressions=2C >>>>> wouldn't >>>>> this create issues with release timeline? >>>>> Am I right to assume=2C release RTC process starts X days before plan= ned >>>>> release date=2C so that issues identified can be fixed? >>>>> Do we allow releases to be made with known bugs? >>>>> >>>>> Regards=2C >>>>> Adi >>>>> >>>>> -----Original Message----- >>>>> From: Markus Gei=C3=9F [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=2C so the Forking Workfl= ow >>>>>> isn't available. I'd recommend just using branches within the main >>>>>> repo. >>>>>> >>>>> >>>>> Just to be clear=2C I was talking about the general approach for >>>>> contributions=2C 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=2C 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') =3B o) >>>>> >>>>> Best=2C >>>>> >>>>> Markus >>>>> >>>>> .::YAGNI likes a DRY KISS::. >>>>> >>>>> Date: Thu=2C 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=2C Dec 24=2C 2015 at 2:19 PM=2C 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 AS= F >>>>>>> documentation ... but I'm fine doing a commit instead of pre callin= g >>>>>>> it out that makes totally more sense to me. >>>>>>> >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> >>>>>>> Markus >>>>>>> >>>>>>> >>>>>>> ::: YAGNI likes a DRY KISS ::: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu=2C Dec 24=2C 2015 at 11:54 AM -0800=2C "Roman Shaposhnik" < >>>>>>> roman@shaposhnik.org> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu=2C Dec 24=2C 2015 at 9:02 AM=2C Greg Stein >>>>>>> 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=2C then why create a JIR= A >>>>>>>> >>>>>>> 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=2C integration with GH pull requests=2C etc. that= are >>>>>>> simply too tedious to do using pure mailing list workflow. >>>>>>> >>>>>>> Now=2C I agree with you that fixing a one liner probably shouldn't >>>>>>> require JIRA -- everything else just use JIRA as your community TOD= O >>>>>>> list. >>>>>>> >>>>>>> In fact=2C enter *ideas* into JIRA=2C keep things marked for newbie= s=2C >>>>>>> etc. >>>>>>> >>>>>> etc. >>>>> >>>>>> This is=2C again=2C where JIRA shines over mailing list -- if somebo= dy >>>>>>> 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=2C if used for features. >>>>>>>> >>>>>>> >>>>>>> Not always. I fine it useful=2C for example=2C to track evolution o= f a >>>>>>> proposals or blueprints. And yes=2C 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=2C 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=2C a vote bas= ed >>>>>>>>> on lazy >>>>>>>>> >>>>>>>> consensus >>>>>>> >>>>>>>> is initiated with a message like "This solves issue >>>>>>>>> FINERACT-1234=2C if no-one objects within three days=2C I'll assu= me >>>>>>>>> lazy consensus and commit >>>>>>>>> >>>>>>>> it." >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> That is not CTR. Commit straight away. Don't wait. "This looks >>>>>>>> good to >>>>>>>> >>>>>>> me. >>>>>>> >>>>>>>> " >>>>>>>> >>>>>>>> You use the term "object"=2C but that isn't quite right. Commit th= e >>>>>>>> >>>>>>> change. >>>>> >>>>>> Others can review. If they have *issues* with the change=2C then you >>>>>>>> begin >>>>>>>> >>>>>>> a >>>>>>> >>>>>>>> discussion. Not an objection. >>>>>>>> >>>>>>>> The goal is to *fix* what was committed. Not to object to it=2C an= d >>>>>>>> roll it back. When the commit lands in the repository=2C then revi= ew >>>>>>>> >>>>>>> happens (CTR). >>>>> >>>>>> And based on the review=2C 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=2C >>>>>>>> or even to the "develop" main branch. Why not? If it breaks >>>>>>>> something=2C >>>>>>>> >>>>>>> then fix it. >>>>> >>>>>> Worst >>>>>>> >>>>>>>> case=2C it can always be backed out. >>>>>>>> >>>>>>>> TRUST each other to commit working code=2C and fixes=2C 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=2C >>>>>>>> >>>>>>> and >>>>>>> >>>>>>>> let them work. Contributions are *always* a bonus=2C and very rare= ly >>>>>>>> a >>>>>>>> >>>>>>> harm. >>>>>>> >>>>>>>> So optimize for the former. >>>>>>>> >>>>>>> >>>>>>> Huge +1 to the above! >>>>>>> >>>>>>> Thanks=2C >>>>>>> Roman. >>>>>>> >>>>>>> >>>>> >>>>> >>>