As long as the branch can be removed later. I am not sure it can. Would need to check first.
You could squash commits and rebate before pushing on master then. -- Clebert Suconic typing on the iPhone. > On Jun 9, 2015, at 22:34, Daniel Kulp <[email protected]> wrote: > > >> 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 >
