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:[email protected]] Sent: 25 December 2015 20:51 To: [email protected] 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: [email protected] > To: [email protected] > > Which doc? I need to fix it :-) > > On Thu, Dec 24, 2015 at 2:19 PM, <[email protected]> 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" < > > [email protected]> wrote: > > > > > > > > > > > > On Thu, Dec 24, 2015 at 9:02 AM, Greg Stein <[email protected]> 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. > >
