cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Stevens <williamstev...@gmail.com>
Subject Re: [DOCS] Git Flow
Date Fri, 23 May 2014 13:01:37 GMT
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.Turner@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: rohityadav89@gmail.com [mailto:rohityadav89@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.Turner@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: williamstevens@gmail.com [mailto:williamstevens@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message