+1 Nicely written, Dan. Thanks! On Tue, Jun 9, 2015, 5:22 PM 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 > >
