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
