Thanks Pat, I'll update winconfig.h and the notice file.
On Tue, Apr 21, 2015 at 10:53 AM, Patrick Hunt <ph...@apache.org> wrote: > Looks like version strings are in src/c/include/winconfig.h that need to be > updated. They are still listed as 3.5.0. > > I think you'll need to spin a new RC to address this. > > You might update the notice file to include 2015 at the same time (not a > blocker typically though). > > Patrick > > On Mon, Apr 20, 2015 at 5:41 PM, Raúl Gutiérrez Segalés <r...@itevenworks.net >> wrote: > >> On 20 April 2015 at 13:03, Raúl Gutiérrez Segalés <r...@itevenworks.net> >> wrote: >> >> > -1, alas. >> > >> > I think ZOOKEEPER-1506 could be problematic for some setups. After a >> > couple of elections with a cluster of 5 participants and one observer, I >> > end up with a participant that's unable to find the leader because it >> does >> > a reverse lookup (IP -> hostname) and ends up with a bogus hostname that >> it >> > can't resolve: >> > >> > https://gist.github.com/rgs1/d11822799fdbbfa5d5f2 >> > >> > I don't think the reverse lookup from QuorumCnxManager was done before, >> > nor that it should be done. So it could cause issues in places where >> > reverse lookups aren't fully working. Surely, we could argue that it's a >> > DNS setup issue but I think we should avoid the extra lookup if possible. >> > >> > I'll dig in a bit deeper and try to come with a deterministic repro. >> > >> >> Commented on ZOOKEEPER-1506: turns out that my issue was with reverse >> lookup calls that were not introduced by that patch. They seem to have been >> introduced by ZOOKEEPER-107, so they have been around for a while. >> >> The tl;dr is that if your resolvers give you bad reverse names, you'll have >> issues. It would nice to avoid these reverse lookups, so I created: >> >> https://issues.apache.org/jira/browse/ZOOKEEPER-2171 >> >> After sorting this issue, I tested the following: >> >> * many elections (which look quick) >> * creating and deleting ephemerals in a loop (via zk-shell) >> * phunt's smoke test scripts (comparable results to 3.5.0) >> * partitioning and unpartioning an attached observer >> * use zktraffic's fle-dump & zab-dump to inspect if there were any bogus >> FLE votes or ZAB messages [0] >> >> All of this looks good! So +1 now :-) >> >> >> -rgs >> >> p.s.: fwiw, here's my test setup: http://itevenworks.net/zk-releases >> >> [0] https://github.com/twitter/zktraffic >> >> >> >> > >> > -rgs >> > >> > >> > >> > >> > On 12 April 2015 at 14:58, Michi Mutsuzaki <mi...@cs.stanford.edu> >> wrote: >> > >> >> This is a release candidate for 3.5.1-alpha. The full release notes is >> >> available at: >> >> >> >> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12326786 >> >> >> >> *** Please download, test and vote by April 25th 2015, 23:59 UTC+0. *** >> >> >> >> Source files: >> >> http://people.apache.org/~michim/zookeeper-3.5.1-alpha-candidate-0/ >> >> >> >> Maven staging repo: >> >> >> >> >> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.5.1-alpha/ >> >> >> >> The tag to be voted upon: >> >> https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.1-rc0/ >> >> >> >> ZooKeeper's KEYS file containing PGP keys we use to sign the release: >> >> http://www.apache.org/dist/zookeeper/KEYS >> >> >> >> Should we release this candidate? >> >> >> >> --Michi >> >> >> > >> > >>
