> 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. > >
