incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Xu <Xuefei...@citrix.com>
Subject RE: git branching & commits list
Date Wed, 01 Aug 2012 19:20:59 GMT

> > 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


Mime
View raw message