couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: [VOTE] Apache CouchDB 1.2.0 release, second round
Date Mon, 27 Feb 2012 17:41:14 GMT

On Feb 27, 2012, at 18:19 , Noah Slater wrote:

> On Mon, Feb 27, 2012 at 1:15 PM, Jan Lehnardt <> wrote:
>> It is interesting that 1.2.x won't hang.
> There is no difference between the files you have on your branch, and the
> files in the release tarball.

For me both hang.

> You can verify this yourself by following the steps here:
> How may times have you tested this?
> If you run "make check" on the branch 5 times, how many fail?
> If you run "make check" from the tarball 5 times, how many file?

They all fail. Only occasionally it doesn't. I can't give it a number,
but maybe it is 1 in 10 runs.

> The question here is whether `make check` passing in R15B is a release
>> requirement. In my vote I considered no, but I am happy to go with a
>> community decision if it emerges. What is your take here?
> Yes, this is a release blocker.

See for details on
this. So far we haven't been able to show that this happens on systems
other than Mac OS X 10.7.3. If true, I wouldn't consider this a release

>>> In the command line tests, 2,7, 27, and 32 fail. but it differs from run
>>> to run.
>> I assume you mean the JS tests. Again, this isn't supposed to work in
>> 1.2.x. I'm happy to backport my changes from master to 1.2.x to make that
>> work, but I refrained from that because I didn't want to bring too much
>> change to a release branch. I'm happy to reconsider, but I don't think a
>> release vote is a good place to discuss feature backports.
> Jan, I am starting to think of our release vote rounds as release
> candidates. In so much as, the activity they seem to kick-off seems to be
> the sort of activity you hope to kick off with a regular release candidate.
> Does that make sense? Within that context, I think it's fine to talk about
> stuff like this. A release voting round is a prompt for people to get their
> shit together.

That's a fair point of view, but I'm looking at this differently. A release
branch should be in good shape most of the time and signing off on a release
by a vote should be a formality, not start discussions what the scope of the
release is.

I'm actually thinking about introducing proper RC release to bridge the
attention / release gap, but that's a separate discussion.

>>> On Chrome attachment_ranges fails and it hangs on replicator_db
>> This one is an "explaining away", but I think it is warranted. Chrome is
>> broken for attachment_ranges. I don't know if we reported this upstream
>> (Robert N?), but this isn't a release blocker. For the replicator_db test,
>> can you try running that in other browsers. I understand it is not the best
>> of situation (hence the move to the cli test suite for master), but if you
>> get this test to pass in at least one other browsers, this isn't a problem
>> that holds 1.2.x.
> We only support Firefox with the test suite. What am I missing?

Many people don't use Firefox :)


View raw message