+1. Although Only question I have: With git it's not really needed to create a branch in the main repo for temporary branches.
But If someone did it thought. Is it easy to remove a branch with Apache git? I have the impression that you need Infra guys to delete branches? If only infra structure guys can delete branches I would not encourage branches on the main repo. -- Clebert Suconic typing on the iPhone. > On Jun 9, 2015, at 20:22, Daniel Kulp <dk...@apache.org> wrote: > > I guess if it was up to me to actually write a formal doc describing the > process it would go something like: > > > ——————— > > ActiveMQ uses a Commit-Then-Review process for getting changes contributed to > the development branches. In general, this means the ActiveMQ committers > are free to directly commit their own work to master and push those changes > to the canonical repository at Apache. However, the expectation is that the > developer has made a good effort to test their changes and is reasonably > confident that the changes that are being committed will not “break the > build.” > > What does it mean to be reasonably confident? That may depend on the > developer. If the developer has run the same maven commands that the CI > builds are running, they can likely be reasonably confident. However, if > the changes are significant, touches a wide area of code, or even if the > developer just wants a second opinion, they are encouraged to engage other > members of the community to obtain an additional review prior to commit. > This can easily be done via a pull request on github, a patch file attached > to an email or JIRA, committed to a branch in the Apache git repo, etc… > There are a variety of options open to them. Having additional eyes > looking at significant changes prior to committing to the main development > branches is definitely encouraged if it helps obtain the “reasonable > confidence” that the build is not broken and code quality has not decreased. > We also have automatic builds setup to test github pull requests in advance > to help establish a good level of confidence in the build. > > However, “things happen”. We’re all human. In the case where the build > does break, the expectation is that the developer will make a best effort to > get the builds fixed in a reasonable amount of time. If it cannot be fixed > in a reasonable amount of time, the commit can be reverted and re-reviewed. > > ——————— > > Everyone: does that about cover it? Did I miss anything? The github > pull requests and gui tools are definitely a good tool chain in certain cases > and I would still encourage those folks that find value in them to continue > using them. However, they cannot be “required”. > > > Dan > > > > > > >>> On Jun 9, 2015, at 7:57 PM, Clebert Suconic <clebert.suco...@gmail.com> >>> wrote: >>> >>> +1 to stay with the existing CTR practice that is well established in the >>> ActiveMQ community. That's why committership is granted. It's a level of >>> trust and confidence that you don't make low hanging fruit errors. >> >> I actually screw up all the time ;) But I rather make eventual >> mistakes than not do something :) >> >> Anyways... lets keep the pull requests as a tool. For instance I just >> prevented an issue because of a PR Build >> >> https://builds.apache.org/job/ActiveMQ-Artemis-PR-Build/418/ >> https://github.com/apache/activemq-artemis/pull/22 >> >> But I don't want to talk about the issue itself on this Thread... This >> is a meta discussion.. I will talk about the issue itself on another >> post I'm about to make > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com >
