Our first goal is always reliability, "it goes without saying" which
is why I didn't highlight it. Every release shoots for the highest
level of reliability we can provide. I think everyone is in agreement
on that. If we find a serious issue we take it seriously, _that's_ why
we had a number of follow-on fix releases so quickly.

That said, 3.4 is not currently "stable", it's alpha/beta/gamma
whatever that means these days. It was discussed on list although that
didn't make it into the announce as clearly as I would have liked.

On the soapbox side, we rely on everyone to help us guarantee
reliability of a release. It's not "the commiitters job" or the PMC's
job, etc... It's the community's job. So if you have issues look to
yourself first. :-) Find the bugs, report them, help us fix them and
improve the existing tests -- if you notice that's exactly what we did
as a result of getting 3.4.0 out there and in more user's hands. If
you think we should do a better job in testing, well, then add more
tests (that's what I do).

Regards,

Patrick

On Wed, Jan 4, 2012 at 11:46 AM, Mark Miller <markrmil...@gmail.com> wrote:
> On Wed, Jan 4, 2012 at 2:42 PM, Thomas Koch <tho...@koch.ro> wrote:
>
>> Patrick Hunt:
>> > It's fine to discuss the roadmap on list. We should only be making
>> > decisions on list regardless. Last I heard from Mahadev he was
>> > coordinating the meetup for sometime this month or early next.
>>
>> So just for the record, I don't expect many to agree:
>>
>> It's my understanding that ZooKeepers first duty is reliability. The last
>> major release (3.4.0) however was immediately followed by two bugfix
>> releases
>> and jira already shows another 5 blockers and 27 critical bugs.
>>
>> Maybe it would be a good idea now to make robustness and stability the
>> first
>> priority and refuse any new features for the next time.
>>
>> As for Patrick's idea of scalability I think that there is a lot of
>> potential
>> to make ZK scale even more. I've already outlined the idea of an immutable
>> datatree and the possibility to handle read requests in parallel,
>> independent
>> from the write queue. The recently discussed "Disruptor" system[1] is also
>> worth a look for inspiration. But it would be hazardous if not impossible
>> to
>> explore any such path without cleaning up the code first.
>>
>> [1] http://code.google.com/p/disruptor
>>
>> Best regards,
>>
>> Thomas Koch, http://www.koch.ro
>>
>
>
> That release (3.4) was kind of oddly post scripted as an alpha. I didn't
> catch that at first but did eventually.
>
> --
> - Mark
>
> http://www.lucidimagination.com

Reply via email to