On Feb 27, 2012, at 18:19 , Noah Slater wrote: > On Mon, Feb 27, 2012 at 1:15 PM, Jan Lehnardt <j...@apache.org> 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: > > http://wiki.apache.org/couchdb/Test_procedure > > 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 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. >> >> 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 :) Cheers Jan --
