couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: 1.2.0 status update
Date Wed, 14 Mar 2012 17:23:39 GMT
We've waited just shy of two weeks now. How long before a fix lands? If
you're proposing that we delay the release again, I need to know by how
much you plan to delay the release. Looking at Paul and BenoƮt here.

On Wed, Mar 14, 2012 at 4:23 PM, Wendall Cada <> wrote:

> +1 On what Benoit says.
> I'll be using the current iteration of this patch to update the couchdb
> rpm spec I've been working on. Additionally, I've opened a dialog with the
> Redhat package maintainer about the possibility of maintaining or
> contributing to this package for RHEL/Centos and Fedora. This can be an
> issue for any distribution package maintainer.
> Wendall
> On 03/13/2012 09:04 PM, Benoit Chesneau wrote:
>> On Tue, Mar 13, 2012 at 7:47 PM, Jason Smith<>  wrote:
>>> IMHO:
>>> It affects advanced users, with multiple JS builds installed. It is
>>> not a 1.2.0 blocker. It's not relevant to this discussion.
>> It is. If you reread the ticket it appears that the problem is more
>> important than expected and I hesitated a lot to let it as blocker
>> like it was initially. Since the release have been postponed, we aslo
>> have the perfect opportunity to really fix that issue.
>> Lot of our users are complaining to have some problem installing
>> couchdb on their machine. This isn't new. This isn't solved.
>> While the lazy solution was to direct them to couchbase stuff, or
>> these days to build_couchdb or rcouch, I would really prefer we fix
>> this *important* issue and let people choose if they prefer to install
>> via a vendor or the official *distribution*. Last iteration of the
>> patch fix most of the cases I guess. We can choose like said above to
>> use this version and fix latest issues in next minor release or trying
>> to solve that last one.  At this point, after different iterations,
>> feedback is appreciated and that is the main reason why updates of the
>> tickets are sent to the ml.
>> - benoit

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message