> 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
