Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1257)
Subject: Re: [VOTE] Apache CouchDB 1.2.0 release, second round
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: 
 <CA+Y+447cqxD95qjOxgXr=8kz1vYSYCmmn1xNqzePiREZVhAwYA@mail.gmail.com>
Date: Mon, 27 Feb 2012 18:41:14 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <EE7AB2B0-85B5-47FE-97B4-78CCB22A2BD7@apache.org>
References: 
 <CA+Y+4475J_wPbiC=g2R6CcqUfQ-_V6TTTxV2iS4xTbz9a10+Xw@mail.gmail.com>
 <7B1F0622-1915-423B-B87C-B0B7B0F1DF59@apache.org>
 <CA+Y+446fB7=HEr4qbXQYu2We5E+caXVOx=d59JGifJ=brTRj=w@mail.gmail.com>
 <E100A5F0-8F65-461E-B01F-4E5ACD4742B8@dionne-associates.com>
 <9369133A-E3FA-48A6-B6A4-F6ADE6486A06@dionne-associates.com>
 <04AC882B-F084-48DB-BF8F-39BFEC158899@apache.org>
 <8FDD55B6-A244-4E10-BC3F-CC42EADDA9A7@dionne-associates.com>
 <85846B78-84B0-47F0-8C9F-28A2326EFB29@apache.org>
 <5E39335F-177A-4B1B-AC8D-57500CF09092@dionne-associates.com>
 <8B5F61DD-C5FA-49A0-A369-91513A1A342D@apache.org>
 <CA+Y+447cqxD95qjOxgXr=8kz1vYSYCmmn1xNqzePiREZVhAwYA@mail.gmail.com>
To: dev@couchdb.apache.org


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

> On Mon, Feb 27, 2012 at 1:15 PM, Jan Lehnardt <jan@apache.org> wrote:
>=20
>> It is interesting that 1.2.x won't hang.
>>=20
>=20
> 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:
>=20
> http://wiki.apache.org/couchdb/Test_procedure
>=20
> How may times have you tested this?
>=20
> If you run "make check" on the branch 5 times, how many fail?
>=20
> 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?
>>=20
>=20
> Yes, this is a release blocker.

See https://issues.apache.org/jira/browse/COUCHDB-1424 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
blocker.


>>> In the command line tests, 2,7, 27, and 32 fail. but it differs from =
run
>>> to run.
>>=20
>> 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.
>=20
>=20
> 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
>>=20
>> 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.
>=20
>=20
> We only support Firefox with the test suite. What am I missing?

Many people don't use Firefox :)

Cheers
Jan
--=20