> On Jun 9, 2015, at 9:56 PM, Clebert <[email protected]> wrote: > > +1. Although Only question I have: > > With git it's not really needed to create a branch in the main repo for > temporary branches.
Depends on the purpose….. If I was going to work on a relatively large idea/change and want to collaborate with another committer, a branch at Apache makes a lot of sense. For example, I’m thinking about creating one to work on the CXF change. I can keep working on it, all commits would still go to the commits@ list so everyone can see what’s going on. Others could help out, etc… Once “done”, it could be merged to master and the branch removed. > 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. The only branch you cannot remove is master. Anything else is just like normal. Dan > > -- Clebert Suconic typing on the iPhone. > >> On Jun 9, 2015, at 20:22, Daniel Kulp <[email protected]> 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 <[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 >> >> -- >> Daniel Kulp >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
