On Tue, Jul 24, 2012 at 9:35 PM, Brett Porter <[email protected]> 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
