Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

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


+
Flavio Junqueira 2012-01-20, 17:25
+
Alexander Shraer 2012-01-20, 18:47
+
Benjamin Reed 2012-01-20, 23:29
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
+
Flavio Junqueira 2012-01-21, 09:02
+
Ted Dunning 2012-01-21, 09:09
+
Patrick Hunt 2012-01-26, 00:25
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB