Flavio Junqueira: > This message is to throw the idea and get a sense of what people > think, especially the ones working closely on it like Alex, about > creating a branch for the reconfiguration work. The rationale for > proposing it is the following. In our experience with Zab last year, > we implemented modifications that introduced a bunch of critical bugs. > I'm not sure whether we could have been more careful, maybe so, but my > perception is that it is not unusual to introduce such bugs once one > touches upon a large chunk of core code. Perhaps it would have been > better to develop it on the side and test more before merging. > > For reconfiguration, it sounds like we will be touching a big chunk of > core code again, so I wonder if it makes sense to work on a separate > branch, test, and merge once we are convinced. I must also say that I > understand that merging branches can be quite a pain, so I would > completely understand if the general feeling is that it outweighs the > benefits. > > Thanks, > -Flavio
Hi Flavio, I've been working with the Git mirror of ZooKeeper and a Git branch of my proposed patches for two months, constantly (daily) rebasing my work against trunk. Every commit in my branch reflected a jira issue. If an issue got accepted into trunk, I rebased by Git branch on top of the new trunk but without the respectiv commit: https://github.com/thkoch2001/zookeeper/commits/proposed_patches It's not as hard as it sounds and it keeps your changes current instead of a merge nightmare after weeks of separated development in trunk and in your branch. I believe, that there is still a lot of valuable refactoring in the above branch that would make any ZK development a lot easier. A Subversion branch won't help you, I think. Best regards, Thomas Koch, http://www.koch.ro
