On Fri, Jun 21, 2013 at 07:53:21PM +0000, Edison Su wrote: > > Edison, > > > > My understanding of our process is that the merges of significant changes > > should be proposed to the mailing list with the "[MERGE]" tag and wait up to > > 72 hours for feedback. I consider interface changes to meet that criteria > > given the potential to break other folks work. It sounds like we had a > > change > > that inadvertently slipped through without notice to list. Going forward, I > > The problem of current merge request, is that, you don't know what > kind of change the merge request did, unless you dig into the code. > Let's say, there is a merge request, the code touches both vm and > storage code, then how do I know, by just taking look at the > request, that, the storage part of code is been changed. > As there are lot of merge requests, a single person can't review all > the merge requests, then likely, the change is slipped without the > notice to other people who wants to review storage related code, > even if the merge request is send out to the list. > > Maybe, we should ask for each merge request, need to add a list of > files been changed: like the output of "git diff --stat"?
Edison, I think the problem is easily solved if people learn to do "rebase" instead of "merge". When we diverge into topic branches for our features we end up in complete silos. If you do a regular rebase of your topic branch you are aware of the changes happening on the master branch. That precludes everyone from having to look at review/merge requests. Eg: If dev A is doing feature X that disrupts dev B doing feature Y both in their own branches. If dev A brings in his feature first to master and dev B rebases on top, B knows that his feature breaks when he rebases against master above dev A's feature X. By doing a merge B simply assumes his feature works alongside A's feature. At least then B, even if he ignored the merge request from A, will make noise on the list to fix it appropriately in collaboration with A. Our proposals /specs already include all the db changes and api changes. But like you said, not everyone is looking at them and preemptively nipping the possiblity of such conflicts. So a more pro-active process of keeping master as the one true state of the project and working additively on top of each other will prevent these frustrations. What do you think? -- Prasanna., ------------------------ Powered by BigRock.com
