> On Jun 9, 2015, at 10:15 AM, Clebert Suconic <[email protected]> > wrote: > > 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.
Well, I fixed that situation this morning. I *THOUGHT* we had a CI build that was running on master on all commits. That was the expectation and if something broke I would have gotten a “this is broken” email within 15 minutes or so. It turns out we didn’t have a build setup for that. We do now. > I'm asking if you could at least send a PR and wait for the build to finish. How do I do a pull request that doesn’t involve github? I’m not using github for development. Dan > 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 <[email protected]> wrote: >> >>> On Jun 8, 2015, at 2:07 PM, Bruce Snyder <[email protected]> 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> >>>>>> To: [email protected] >>>>>> 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 <[email protected]> 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" <[email protected]> >>>>>>> To: [email protected] >>>>>>> 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 >>>>>> [email protected] - 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 >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> > > > > -- > Clebert Suconic > http://community.jboss.org/people/[email protected] > http://clebertsuconic.blogspot.com -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
