All good feedback. Thanks. I will rework this on Monday and add a PR for adding it to the readmes.
Thx, Will On Friday, May 23, 2014, Stephen Turner <stephen.tur...@citrix.com> wrote: > I've not seen Phabricator, but yes, what I like about github is that the code review is built into the source control. This makes the whole workflow much simpler. > > -- > Stephen Turner > > > -----Original Message----- > From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On Behalf Of Rohit Yadav > Sent: 23 May 2014 11:35 > To: dev@cloudstack.apache.org > Cc: Sebastien Goasguen; Pierre-Luc Dion > Subject: Re: [DOCS] Git Flow > > Hi, > > Good effort. Will you should also see this and update the wiki as needed: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git > > I would say, squashed merges are much better when you're going through list of changes [1] instead of having a branch based workflow, reverting/fixing/bisecting it becomes much easier. I would recommend Stephen and others to checkout Phabricator's pre and post code reviewing and their CLI tool arcanist which IMO give a much better workflow. > > Right now it's too much pain for a contributor to create a patch, upload to reviewboard, get it reviewed and then for the committer to go see RB, test/review patch and merge it. This is all manual work. Pull request is one good way to solve it at the cost of complicating git trees/graphs, emailing patch directly to ML can be another (historically worked?) and using something like Phabricator (that can be hosted on ASF infra) is another way as well. > > [1] See the git network/graph: git log --graph --decorate --pretty=oneline --abbrev-commit --all > > Regards. > > > On Fri, May 23, 2014 at 3:20 PM, Stephen Turner > <stephen.tur...@citrix.com>wrote: > >> I'm not a fan of squashed merges myself, because you lose the history, >> which can often contain useful check-in comments. >> >> My preferred github workflow is to make a new local branch before >> starting any change, push that to a branch in my fork of the project >> on github, and then send a pull request. I don't do subsequent work on >> the same branch (unless the maintainer wants further changes before >> accepting the pull request), so I don't run into the problem where >> pull requests build on each other. >> >> Having said that, I'm talking about code, not documentation. There may >> be some reason I'm not aware of why documentation works better with a >> different workflow. >> >> -- >> Stephen Turner >> >> >> -----Original Message----- >> From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On >> Behalf Of Will Stevens >> Sent: 22 May 2014 21:36 >> To: dev@cloudstack.apache.org; Sebastien Goasguen; Pierre-Luc Dion >> Subject: [DOCS] Git Flow >> >> Hey All, >> In the the README.rst files in the documentation, it refers to this >> page if you want to contribute: >> http://cloudstack.apache.org/developers.html >> >> I am not sure those instructions are actually up-to-date or valid for >> contributing to the documentation. >> >> I originally tried to use this process ( >> https://help.github.com/articles/syncing-a-fork) to keep my >> documentation fork up-to-date with the upstream/master, but after the >> first pull request the commits have to be cherry-picked because the >> pull requests will always take everything I have committed in my fork >> rather than the changes since the last pull request. This got annoying quickly. >> >> When contributing to the actual CloudStack code I used a squashed >> patch approach which worked very well. I have written up that flow as >> well as a similar flow for working with Github pull requests. >> >> I would like you to review what I have written. If you guys approve >> of the flow, I would like to add it to the README.rst files in the >> different documentation repositories to make it easier for people to >> contribute to the documentation. I know I found it really hard to >> figure out how to contribute to the documentation initially. We want >> to lower the bar a bit on this so more people feel comfortable helping with the documentation. >> >> L
