> 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
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:
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
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.
Thomas Koch, http://www.koch.ro