I just canceled the patch for 1810 because it doesn't apply anymore.
It's good to go once the patch is rebased.

On Wed, Jul 2, 2014 at 9:19 PM, Patrick Hunt <ph...@apache.org> wrote:
> Update: we're down to 7 blockers on 5.1.0 (from 8 in the last check).
> 1810 is waiting on feedback from Michi, and Camille is threatening to
> commit 1863. I see some great progress in general on the patch
> availables queue, which is great to see.
>
> So here's something else we might consider - should we drop jdk6
> support from 3.5. It's long since EOL by Oracle but I suspect some
> folks are still using ZK with 6. We gotta move forward though, can't
> support it forever. Thoughts? Note that we are currently
> building/testing trunk against jdk6, 7 and 8.
> https://builds.apache.org/view/S-Z/view/ZooKeeper/
>
> Patrick
>
> On Tue, Jul 1, 2014 at 2:26 AM, Flavio Junqueira
> <fpjunque...@yahoo.com.invalid> wrote:
>> According to me, ZK-1810 should be in already, but I need a +1 there. I 
>> think Michi hasn't checked in because LETest failed in the last QA run 
>> there. However, that patch doesn't affect LETest, and in fact it fails in 
>> trunk intermittently, so the test failure doesn't seem to be related to the 
>> patch.
>>
>> I haven't checked ZK-1863, so I can't say anything concrete about it.
>>
>> -Flavio
>>
>>
>>
>> On Tuesday, July 1, 2014 5:53 AM, Patrick Hunt <ph...@apache.org> wrote:
>>
>>
>>>
>>>
>>>Hi Flavio, do you think those jiras can get reviewed/finalized before
>>>the end of the week? I'd like to try cutting an RC soonish...
>>>
>>>Patrick
>>>
>>>
>>>On Sun, Jun 29, 2014 at 5:02 AM, Flavio Junqueira
>>><fpjunque...@yahoo.com.invalid> wrote:
>>>> +1 for the plan of releasing alpha versions.
>>>>
>>>> I'd like to have ZK-1818 (ZK-1810) and ZK-1863 in. They are both patch 
>>>> available. ZK-1870 is in trunk, but it is still open because we need a 3.4 
>>>> patch.
>>>>
>>>> -Flavio
>>>>
>>>>
>>>> On 26 Jun 2014, at 01:07, Patrick Hunt <ph...@apache.org> wrote:
>>>>
>>>>> Hey folks, we've been talking about it for a while, a few people have
>>>>> mentioned on the list as well as contacted me personally that they
>>>>> would like to see some progress on the first 3.5 release. Every
>>>>> release is a compromise, if we wait for perfection we'll never get
>>>>> anything out the door. 3.5 has tons of great new features, lots of
>>>>> hard work, let's get it out in a release so that folks can use it,
>>>>> test it, and give feedback.
>>>>>
>>>>> Jenkins jobs have been pretty stable except for the known flakey test
>>>>> ZOOKEEPER-1870 which Flavio committed today to trunk. Note that
>>>>> jenkins has also been verifying the code on jdk7 and jdk8.
>>>>>
>>>>> Here's my thinking again on how we should plan our releases:
>>>>>
>>>>> I don't think we'll be able to do a 3.5.x-stable for some time. What I
>>>>> think we should do instead is similar to what we did for 3.4. (this is
>>>>> also similar to what Hadoop did during their Hadoop 2 release cycle)
>>>>> Start with a series of alpha releases, something people can run and
>>>>> test with, once we address all the blockers and feel comfortable with
>>>>> the apis & remaining jiras we then switch to beta. Once we get some
>>>>> good feedback we remove the alpha/beta moniker and look at making it
>>>>> "stable'. At some later point it will become the "current/stable"
>>>>> release, taking over from 3.4.x.
>>>>>
>>>>> e.g.
>>>>> 3.5.0-alpha (8 blockers)
>>>>> 3.5.1-alpha (3 blockers)
>>>>> 3.5.2-alpha (0 blockers)
>>>>> 3.5.3-beta (apis locked)
>>>>> 3.5.4-beta
>>>>> 3.5.5-beta
>>>>> 3.5.6 (no longer considered alpha/beta but also not "stable" vs 3.4.x,
>>>>> maybe use it for production but we still expect things to shake out)
>>>>> 3.5.7
>>>>> ....
>>>>> 3.5.x - ready to replace 3.4 releases for production use, stable, etc...
>>>>>
>>>>> There are 8 blockers currently, are any of these something that should
>>>>> hold up 3.5.0-alpha?
>>>>>
>>>>> I'll hold open the discussion for a couple days. If folks find this a
>>>>> reasonable plan I'll start the ball rolling to cut an RC.
>>>>>
>>>>> Patrick
>>>>
>>>
>>>
>>>

Reply via email to