You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Brett Porter <br...@apache.org> on 2012/07/25 03:35:39 UTC
git branching & commits list
Hi,
Being based in Sydney, I tend to get a lot of list traffic in one big lump when I wake up. Looking at cloudstack-commits today, there are 139 messages - most of which are a result of git branch merges. This has been the situation a few times before, but this is the largest I recall seeing.
There isn't anything necessarily wrong with that, but it has me thinking about the effectiveness of watching that list to provide oversight on the code being committed. I'm asking this out of interest as a mentor in how the podling deals with internal code review, and also to understand how the ASF can best provide git infrastructure as a relatively new service. I'm not actively developing the project, so I wanted to hear how others who are find working with it.
The VPC branch is the obvious example at the moment. It has been active since June 15, and has this breakdown of commits:
- 232 unique commits
- 14 merge commits
- 259 commits merged from master
So this seems like a good period of time and work to review. Do the other developers here feel they adequately understand what is happening on a feature branch such as this, both in terms of the overall plan for the branch, and the review of the specific commits? Is the commits list remaining an effective tool to keep track of this information?
Regards,
Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
RE: git branching & commits list
Posted by Will Chan <wi...@citrix.com>.
I also would like to know if everyone in the community does understand what is being put into this branch because at some point, the developers of this feature branch would probably ask the community to when they can merge back into master. I would hope it wouldn't be a big surprise when this happens.
If people are confused to what is being patched/merge here, please shout out so we can correct it ASAP.
Will
________________________________________
From: Brett Porter [brett@porterclan.net] On Behalf Of Brett Porter [brett@apache.org]
Sent: Tuesday, July 24, 2012 6:35 PM
To: cloudstack-dev@incubator.apache.org
Subject: git branching & commits list
Hi,
Being based in Sydney, I tend to get a lot of list traffic in one big lump when I wake up. Looking at cloudstack-commits today, there are 139 messages - most of which are a result of git branch merges. This has been the situation a few times before, but this is the largest I recall seeing.
There isn't anything necessarily wrong with that, but it has me thinking about the effectiveness of watching that list to provide oversight on the code being committed. I'm asking this out of interest as a mentor in how the podling deals with internal code review, and also to understand how the ASF can best provide git infrastructure as a relatively new service. I'm not actively developing the project, so I wanted to hear how others who are find working with it.
The VPC branch is the obvious example at the moment. It has been active since June 15, and has this breakdown of commits:
- 232 unique commits
- 14 merge commits
- 259 commits merged from master
So this seems like a good period of time and work to review. Do the other developers here feel they adequately understand what is happening on a feature branch such as this, both in terms of the overall plan for the branch, and the review of the specific commits? Is the commits list remaining an effective tool to keep track of this information?
Regards,
Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
Re: git branching & commits list
Posted by Alena Prokharchyk <Al...@citrix.com>.
Here is the original email, from June 15:
On 6/15/12 3:37 PM, "Alena Prokharchyk" <Al...@citrix.com>
wrote:
>In the next official cloudStack Citrix release, one of the big features is
>InterVlan. The feature development is still going on, and we don't want to
>push changes to ASF master until we write/execute proper unit tests for
>all new modules + integration with the current ones. I created a separate
>branch out of asf/master and called it "vpc". All existing interVlan
>changes are already in the branch, and all new interVlan related checkins
>will be propagated there as well. So whoever is interested in getting
>familiar with the feature / new code, checkout the asf/vpc branch. Code
>review and suggestions are appreciated.
>
>Here is the related functional spec:
>
>http://wiki.cloudstack.org/display/RelOps/Inter-VLAN+Routing+functional+sp
>e
>c
>
>
>Once the feature is stabilized and unitested properly, we are going to
>merge it to asf/master. The merge patch will be split into components to
>make it easier for review: VPC client APIs component, VPC management, VPC
>network element, new set of VirtualRouter scripts for VPC, etc.
>
>
>Thank you,
>-Alena.
>
>
-Alena.
On 7/25/12 2:58 PM, "Alena Prokharchyk" <Al...@citrix.com>
wrote:
>I've sent an email to apache list announcing VPC branch creation in asf
>repo (more than a month ago). The email also included all feature related
>online docs (PRDs/FS).
>
>
>The branch was created as soon as we started VPC feature development. We
>didn't want to merge it to master directly (the feature is too big, still
>in development and isn't covered by unittests just yet). At the same time
>we wanted to enable it to the community asap, therefore asf/vpc branch was
>created. The merge will be done as soon as the feature is properly tested
>in the topic branch.
>
>Resending the functional spec for the feature:
>
>http://wiki.cloudstack.org/display/RelOps/Inter-VLAN+Routing+functional+sp
>e
>c
>
>-Alena.
>
>On 7/25/12 2:46 PM, "Wido den Hollander" <wi...@widodh.nl> wrote:
>
>>
>>
>>On 07/25/2012 03:35 AM, Brett Porter wrote:
>>> Hi,
>>>
>>> Being based in Sydney, I tend to get a lot of list traffic in one big
>>>lump when I wake up. Looking at cloudstack-commits today, there are 139
>>>messages - most of which are a result of git branch merges. This has
>>>been the situation a few times before, but this is the largest I recall
>>>seeing.
>>>
>>
>>Same in the EU. When you wake up your mailbox is loaded with e-mail :)
>>
>>> There isn't anything necessarily wrong with that, but it has me
>>>thinking about the effectiveness of watching that list to provide
>>>oversight on the code being committed. I'm asking this out of interest
>>>as a mentor in how the podling deals with internal code review, and also
>>>to understand how the ASF can best provide git infrastructure as a
>>>relatively new service. I'm not actively developing the project, so I
>>>wanted to hear how others who are find working with it.
>>>
>>> The VPC branch is the obvious example at the moment. It has been active
>>>since June 15, and has this breakdown of commits:
>>> - 232 unique commits
>>> - 14 merge commits
>>> - 259 commits merged from master
>>>
>>> So this seems like a good period of time and work to review. Do the
>>>other developers here feel they adequately understand what is happening
>>>on a feature branch such as this, both in terms of the overall plan for
>>>the branch, and the review of the specific commits? Is the commits list
>>>remaining an effective tool to keep track of this information?
>>>
>>
>>I honestly haven't looked at that branch. I've seen in there, but I
>>think most developers are busy enough with their own daily work.
>>
>>Reviewing other code and understanding what is happening around you is
>>important, but CloudStack is a BIG project.
>>
>>A quick peek at the VPC branch shows me that a lot of UI work is being
>>done there.
>>
>>I understand what they are changing, but as a new committer I can't say
>>that I fully understand what they are working on.
>>
>>Another problem still is that it seems to me that a lot of work is being
>>done in the Citrix offices which the community don't know about.
>>
>>With open source projects I always assume most stuff goes over the
>>mailinglist, but it seems a lot of the work goes through the bugtracker
>>and other channels. I'm missing that information, so I don't have a clue
>>what most developers are working on.
>>
>>Wido
>>
>>> Regards,
>>> Brett
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://brettporter.wordpress.com/
>>> http://au.linkedin.com/in/brettporter
>>> http://twitter.com/brettporter
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
Re: git branching & commits list
Posted by Alena Prokharchyk <Al...@citrix.com>.
I've sent an email to apache list announcing VPC branch creation in asf
repo (more than a month ago). The email also included all feature related
online docs (PRDs/FS).
The branch was created as soon as we started VPC feature development. We
didn't want to merge it to master directly (the feature is too big, still
in development and isn't covered by unittests just yet). At the same time
we wanted to enable it to the community asap, therefore asf/vpc branch was
created. The merge will be done as soon as the feature is properly tested
in the topic branch.
Resending the functional spec for the feature:
http://wiki.cloudstack.org/display/RelOps/Inter-VLAN+Routing+functional+spe
c
-Alena.
On 7/25/12 2:46 PM, "Wido den Hollander" <wi...@widodh.nl> wrote:
>
>
>On 07/25/2012 03:35 AM, Brett Porter wrote:
>> Hi,
>>
>> Being based in Sydney, I tend to get a lot of list traffic in one big
>>lump when I wake up. Looking at cloudstack-commits today, there are 139
>>messages - most of which are a result of git branch merges. This has
>>been the situation a few times before, but this is the largest I recall
>>seeing.
>>
>
>Same in the EU. When you wake up your mailbox is loaded with e-mail :)
>
>> There isn't anything necessarily wrong with that, but it has me
>>thinking about the effectiveness of watching that list to provide
>>oversight on the code being committed. I'm asking this out of interest
>>as a mentor in how the podling deals with internal code review, and also
>>to understand how the ASF can best provide git infrastructure as a
>>relatively new service. I'm not actively developing the project, so I
>>wanted to hear how others who are find working with it.
>>
>> The VPC branch is the obvious example at the moment. It has been active
>>since June 15, and has this breakdown of commits:
>> - 232 unique commits
>> - 14 merge commits
>> - 259 commits merged from master
>>
>> So this seems like a good period of time and work to review. Do the
>>other developers here feel they adequately understand what is happening
>>on a feature branch such as this, both in terms of the overall plan for
>>the branch, and the review of the specific commits? Is the commits list
>>remaining an effective tool to keep track of this information?
>>
>
>I honestly haven't looked at that branch. I've seen in there, but I
>think most developers are busy enough with their own daily work.
>
>Reviewing other code and understanding what is happening around you is
>important, but CloudStack is a BIG project.
>
>A quick peek at the VPC branch shows me that a lot of UI work is being
>done there.
>
>I understand what they are changing, but as a new committer I can't say
>that I fully understand what they are working on.
>
>Another problem still is that it seems to me that a lot of work is being
>done in the Citrix offices which the community don't know about.
>
>With open source projects I always assume most stuff goes over the
>mailinglist, but it seems a lot of the work goes through the bugtracker
>and other channels. I'm missing that information, so I don't have a clue
>what most developers are working on.
>
>Wido
>
>> Regards,
>> Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://brettporter.wordpress.com/
>> http://au.linkedin.com/in/brettporter
>> http://twitter.com/brettporter
>>
>>
>>
>>
>>
>
Re: git branching & commits list
Posted by Wido den Hollander <wi...@widodh.nl>.
On 07/25/2012 03:35 AM, Brett Porter wrote:
> Hi,
>
> Being based in Sydney, I tend to get a lot of list traffic in one big lump when I wake up. Looking at cloudstack-commits today, there are 139 messages - most of which are a result of git branch merges. This has been the situation a few times before, but this is the largest I recall seeing.
>
Same in the EU. When you wake up your mailbox is loaded with e-mail :)
> There isn't anything necessarily wrong with that, but it has me thinking about the effectiveness of watching that list to provide oversight on the code being committed. I'm asking this out of interest as a mentor in how the podling deals with internal code review, and also to understand how the ASF can best provide git infrastructure as a relatively new service. I'm not actively developing the project, so I wanted to hear how others who are find working with it.
>
> The VPC branch is the obvious example at the moment. It has been active since June 15, and has this breakdown of commits:
> - 232 unique commits
> - 14 merge commits
> - 259 commits merged from master
>
> So this seems like a good period of time and work to review. Do the other developers here feel they adequately understand what is happening on a feature branch such as this, both in terms of the overall plan for the branch, and the review of the specific commits? Is the commits list remaining an effective tool to keep track of this information?
>
I honestly haven't looked at that branch. I've seen in there, but I
think most developers are busy enough with their own daily work.
Reviewing other code and understanding what is happening around you is
important, but CloudStack is a BIG project.
A quick peek at the VPC branch shows me that a lot of UI work is being
done there.
I understand what they are changing, but as a new committer I can't say
that I fully understand what they are working on.
Another problem still is that it seems to me that a lot of work is being
done in the Citrix offices which the community don't know about.
With open source projects I always assume most stuff goes over the
mailinglist, but it seems a lot of the work goes through the bugtracker
and other channels. I'm missing that information, so I don't have a clue
what most developers are working on.
Wido
> Regards,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>
RE: git branching & commits list
Posted by Anthony Xu <Xu...@citrix.com>.
> > So part of me says, silencing merge/cherrypick commits is the way to
> go, but
> > there is a part of me that says that having to hide all of that means
> we are
> > doing something wrong; and the part of me that is concerned with what
> is
> > going on really does want to see all of that.
>
> I don't like the idea of squashing cherrypick mails. Cherrypicks are
> important changes, too, especially for stable branches.
>
> > Is there a better way for us to handle feature development? (esp long
> > running feature development?). Am I just being a wuss for not wanting
> to
> > read all of the duplicate commit mails? What's worse is that I spent
> a good bit
> > of time reviewing commits to this branch - and I am seeing commits
> for Site-
> > to-site VPN, UI development for Autoscale, etc that appear to
> originate and
> > only live in that branch. That brings up a whole different set of
> questions
> > (why are these seemingly disparate features being done in one big
> feature
> > branch? instead of distinct feature branches, etc) Should we be
> expecting
> > feature owners to submit status reports every so often to update the
> list as
> > to how things are proceeding?
>
> CloudStack is a big project that spans many technologies. I wouldn't
> expect any single person to review every commit, or to understand every
> commit even if they did review them given the wide range of
> technologies involved. As the architecture work Alex and others
> proposed continues we'll see improving boundaries in the code and it
> will be easier for people to follow their particular areas of concern
> and interest. In my mind that is the right way to separate interests.
> Ideally commit messages would allow filter/search by area of interest.
>
> I don't understand why multiple features would go into the same feature
> branch. I could potentially see a desire for a feature branch off a
> feature branch where there is a dependency. Perhaps someone can
> explain why this mixing was done with VPC and Autoscale.
VPC and Autoscale have separate branch,
Site-to-Site VPN is only supported in VPC, it is in VPC branch,
As for UI, different features may require UI effort, you may see UI patches in these two branches.
Anthony
RE: git branching & commits list
Posted by Kevin Kluge <Ke...@citrix.com>.
> So part of me says, silencing merge/cherrypick commits is the way to go, but
> there is a part of me that says that having to hide all of that means we are
> doing something wrong; and the part of me that is concerned with what is
> going on really does want to see all of that.
I don't like the idea of squashing cherrypick mails. Cherrypicks are important changes, too, especially for stable branches.
> Is there a better way for us to handle feature development? (esp long
> running feature development?). Am I just being a wuss for not wanting to
> read all of the duplicate commit mails? What's worse is that I spent a good bit
> of time reviewing commits to this branch - and I am seeing commits for Site-
> to-site VPN, UI development for Autoscale, etc that appear to originate and
> only live in that branch. That brings up a whole different set of questions
> (why are these seemingly disparate features being done in one big feature
> branch? instead of distinct feature branches, etc) Should we be expecting
> feature owners to submit status reports every so often to update the list as
> to how things are proceeding?
CloudStack is a big project that spans many technologies. I wouldn't expect any single person to review every commit, or to understand every commit even if they did review them given the wide range of technologies involved. As the architecture work Alex and others proposed continues we'll see improving boundaries in the code and it will be easier for people to follow their particular areas of concern and interest. In my mind that is the right way to separate interests. Ideally commit messages would allow filter/search by area of interest.
I don't understand why multiple features would go into the same feature branch. I could potentially see a desire for a feature branch off a feature branch where there is a dependency. Perhaps someone can explain why this mixing was done with VPC and Autoscale.
-kevin
Re: git branching & commits list
Posted by David Nalley <da...@gnsa.us>.
On Tue, Jul 24, 2012 at 9:35 PM, Brett Porter <br...@apache.org> wrote:
> Hi,
>
> Being based in Sydney, I tend to get a lot of list traffic in one big lump when I wake up. Looking at cloudstack-commits today, there are 139 messages - most of which are a result of git branch merges. This has been the situation a few times before, but this is the largest I recall seeing.
>
> There isn't anything necessarily wrong with that, but it has me thinking about the effectiveness of watching that list to provide oversight on the code being committed. I'm asking this out of interest as a mentor in how the podling deals with internal code review, and also to understand how the ASF can best provide git infrastructure as a relatively new service. I'm not actively developing the project, so I wanted to hear how others who are find working with it.
>
> The VPC branch is the obvious example at the moment. It has been active since June 15, and has this breakdown of commits:
> - 232 unique commits
> - 14 merge commits
> - 259 commits merged from master
>
> So this seems like a good period of time and work to review. Do the other developers here feel they adequately understand what is happening on a feature branch such as this, both in terms of the overall plan for the branch, and the review of the specific commits? Is the commits list remaining an effective tool to keep track of this information?
>
> Regards,
> Brett
>
So I figured I'd circle back to this conversation. While I didn't
begin with this viewpoint when I started writing this message, I have
now begun to believe that this is a much bigger issue than volume of
mails on the commit list.
As much as I hate to admit it I have gotten to the point where I don't
review commits when the username is alena1108.
Brett and I were discussing on IRC whether or not this is a tooling
issue or a process problem, and it has left me confused on that issue,
but also concerned on others.
Philosophically I like the idea of feature branches. Especially for
features where it isn't clear they will be done within a given release
cycles development time frame. The vpc feature branch seems to still
be getting a good bit of development from multiple people. But there
were about 50 or so commit mails again today, and they are the only
ones today that I haven't read through.
In general I think I know what is going on (I saw the VPC func spec
back in May when it hit the list) but I have no idea what the status
currently is, nor have I been keeping up with the commits on that
branch.
So part of me says, silencing merge/cherrypick commits is the way to
go, but there is a part of me that says that having to hide all of
that means we are doing something wrong; and the part of me that is
concerned with what is going on really does want to see all of that.
Is there a better way for us to handle feature development? (esp long
running feature development?). Am I just being a wuss for not wanting
to read all of the duplicate commit mails? What's worse is that I
spent a good bit of time reviewing commits to this branch - and I am
seeing commits for Site-to-site VPN, UI development for Autoscale, etc
that appear to originate and only live in that branch. That brings up
a whole different set of questions (why are these seemingly disparate
features being done in one big feature branch? instead of distinct
feature branches, etc) Should we be expecting feature owners to submit
status reports every so often to update the list as to how things are
proceeding?
--David