Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # dev >> Branch for reconfiguration (ZOOKEEPER-107)?


Copy link to this message
-
Re: Branch for reconfiguration (ZOOKEEPER-107)?
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