The commit-then-review doesn't really scale. If someone breaks stuff that means someone else will have to review and test it.
For instance, yesterday I spent one hour of my catching up time with Game Of Thrones to find what broke the build :) the commit-then-review means that *someone like me* will have to go over and find what broke it. On the case it was the m2e change that opened a JDK bug / Whatever compilation bug. There is no way you could have caught that bug without a CI build that we currently have. I'm asking if you could at least send a PR and wait for the build to finish. For me the workflow is a tool to avoid mistakes, not an enforced rule. So, I don't want to get political on the workflow and I don't want to dictate how you work. If you don't want someone else reviewing your commit, please at least send the PR, wait for a Successful build from the CI, that enhances your testing. If you could wait someone else to merge it do it. If you really don't want to wait push it yourself but I would appreciate if you could at least wait the CI build to finish and avoid errors. (notice I'm saying avoiding... we all break stuff from time to time, so this is just a tool) On Mon, Jun 8, 2015 at 4:02 PM, Daniel Kulp <dk...@apache.org> wrote: > >> On Jun 8, 2015, at 2:07 PM, Bruce Snyder <bruce.sny...@gmail.com> wrote: >> >> In general, there are two approaches to the use of SCM on ASF projects: >> >> 1) Commit then review (CTR) >> 2) Review then commit (RTC) >> >> As Dan pointed out above, the ActiveMQ repo has always been CTR and I see >> no reason to change this. What I asked about is the general workflow used >> on the ActiveMQ repo, not the Artemis repo. I know that Artemis uses Github >> as the primary entry point, but to my knowledge ActiveMQ is not using >> Github in this way. Is this assumption correct? > > Correct. For the most part, the committers on all the repos other than > activemq-artemis push directly to master as they complete development. > Commits are then cherry-picked as needed back to the various fixes branches. > > > Basically, workflow for committers: > > git clone https://git1-us-west.apache.org/repos/asf/activemq.git > work work work work > git commit …. > git pull —rebase > git push origin master > > Obviously there are various “mvn test” things in there. > > Github is not involved at all. > > For non-committers, we certainly can and should encourage github pull > requests. In addition, patches attached to JIRA’s are perfectly acceptable. > > Dan > > > >> Now that we are talking about different workflows for different repos, I >> think we should document the recommended git workflow for both the ActiveMQ >> repo and the Artemis repo (and any repos that get created in the future). >> >> Bruce >> >> On Mon, Jun 8, 2015 at 10:19 AM, Andy Taylor <andy.tayl...@gmail.com> wrote: >> >>> Daniel, >>> >>> Bruce asked about the workflow that committers use today because of some >>> questions that were raised. I dont think any replies are mandating that >>> ActiveMQ should follow a different route they are just commenting on the >>> way they currently work. This is just a discussion about the pros and cons >>> of different approaches as far as I can see and to document what ActiveMQ >>> currently does, I'm not sure this is currently documented. >>> >>> >>> On 08/06/15 17:01, Daniel Kulp wrote: >>> >>>> Apache ActiveMQ has always been “Commit then Review”. This workflow >>>> completely changes that and if you want to start the whole argument about >>>> an external project subsuming the processes that are currently in place for >>>> THIS project, feel free. It likely won’t go well. >>>> >>>> Second, a rule at Apache is if it didn’t appear on our lists, it’s not >>>> done. Thus, anything NOT pushed to Apache hasn’t happened. There isn’t >>>> anything to discuss. Anything you do in your personal github fork is >>>> irrelevant until it appears in the Apache repo and the appropriate commit >>>> messages sent off to the dev list to be reviewed. That’s exactly why I >>>> said feature branches can be done at Apache. >>>> >>>> And your #3 also completely changes how ActiveMQ has worked in the past. >>>> Again, not something to be taken lightly. (and something I would vote >>>> against) >>>> >>>> Dan >>>> >>>> >>>> >>>> On Jun 8, 2015, at 9:54 AM, Justin Bertram <jbert...@apache.com> wrote: >>>>> >>>>> Daniel, the workflow is essentially what I follow as a committer. I >>>>> never push straight to the master on the official Apache repo. GitHub >>>>> offers me a few distinct advantages: >>>>> >>>>> 1. Automated PR builds. I could run the PR build locally but then >>>>> that ties up my machine when I could be working on something else. >>>>> 2. Chance for discussion *before* the commit is made on the official >>>>> Apache repo. If there's something wrong with the PR then you want to >>>>> catch >>>>> it before it's committed, not after. >>>>> 3. Allows someone other than the developer who made the changes to >>>>> merge the commit. This is a rule we follow pretty closely and it should >>>>> probably be specifically outlined in the hackng guide. >>>>> >>>>> BTW, here's some notes specifically for project maintainers: >>>>> https://github.com/apache/activemq-artemis/blob/master/docs/hacking-guide/en/maintainers.md >>>>> >>>>> >>>>> Justin >>>>> >>>>> ----- Original Message ----- >>>>> From: "Daniel Kulp" <dk...@apache.org> >>>>> To: dev@activemq.apache.org >>>>> Sent: Monday, June 8, 2015 8:41:56 AM >>>>> Subject: Re: Git workflow for committers >>>>> >>>>> >>>>> On Jun 8, 2015, at 9:35 AM, Justin Bertram <jbert...@apache.com> wrote: >>>>>> >>>>>> We recently published a Hacking Guide that outlines the typical >>>>>> development cycle: >>>>>> https://github.com/apache/activemq-artemis/blob/master/docs/hacking-guide/en/code.md#typical-development-cycle >>>>>> >>>>>> Improvements are certainly welcome. >>>>>> >>>>> >>>>> I think this is ok for workflow for non-committers. Nice to have that >>>>> documented. Committers should not have to go through github. >>>>> >>>>> In particular: step 4 can just be push your branch to a new branch at >>>>> Apache. There isn’t a need for github for that >>>>> Step 5: if you push to Apache in step 4, all the commits would be on >>>>> the Apache commits list and would be fine for discussion from there. >>>>> Step 7: if you are a committer, just push it to master. There is no >>>>> need for the pull requests from github. >>>>> >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>>> >>>>>> Justin >>>>>> >>>>>> P.S. I already sent a PR to get the references to the old JIRA repo >>>>>> (i.e. ACTIVEMQ6) updated to the new one (i.e. ARTEMIS). >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Bruce Snyder" <bruce.sny...@gmail.com> >>>>>> To: dev@activemq.apache.org >>>>>> Sent: Sunday, June 7, 2015 2:10:14 PM >>>>>> Subject: Git workflow for committers >>>>>> >>>>>> New committer Marc Schöchlin has raised some questions about the git >>>>>> workflow to use as he continues to work on the init scripts. This is a >>>>>> perfect opportunity for all committers to discuss the workflow that we >>>>>> recommend be used when working on ActiveMQ projects and I will document >>>>>> the >>>>>> end result on the wiki in association with the 'How To Become a >>>>>> Committer...' page. >>>>>> >>>>>> After many years of experience with git, I am a big fan of git flow ( >>>>>> http://nvie.com/posts/a-successful-git-branching-model/) but I don't >>>>>> believe that is being used on ActiveMQ. So what is the general git >>>>>> workflow >>>>>> that committers use today? >>>>>> >>>>>> Bruce >>>>>> >>>>>> -- >>>>>> perl -e 'print >>>>>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );' >>>>>> >>>>>> ActiveMQ in Action: http://bit.ly/2je6cQ >>>>>> Blog: http://bruceblog.org/ >>>>>> Twitter: http://twitter.com/brucesnyder >>>>>> >>>>> >>>>> -- >>>>> Daniel Kulp >>>>> dk...@apache.org - http://dankulp.com/blog >>>>> Talend Community Coder - http://coders.talend.com >>>>> >>>> >>>> >>> >> >> >> -- >> perl -e 'print >> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );' >> >> ActiveMQ in Action: http://bit.ly/2je6cQ >> Blog: http://bruceblog.org/ >> Twitter: http://twitter.com/brucesnyder > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > -- Clebert Suconic http://community.jboss.org/people/clebert.suco...@jboss.com http://clebertsuconic.blogspot.com
