On 06/09/2015 08:22 PM, Daniel Kulp 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 > I think that captures it quite nicely, thanks Dan!
> > > > >> On Jun 9, 2015, at 7:57 PM, Clebert Suconic <[email protected]> >> 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 -- Tim Bish Sr Software Engineer | RedHat Inc. [email protected] | www.redhat.com twitter: @tabish121 blog: http://timbish.blogspot.com/
