It's been over a week since this thread started. I've been circling in a holding pattern around current master so as not to create noise that detracts from this RFC and voting. I don't see anything else holding up 1.2. I say, "ship it!"
-Randall On Sun, Jan 15, 2012 at 13:31, Noah Slater <nsla...@tumbolia.org> wrote: > I await your feedback. > > On Sun, Jan 15, 2012 at 7:46 PM, Robert Newson <rnew...@apache.org> wrote: > >> If it's a regression, before. If not, after. >> >> B. >> >> On 15 January 2012 19:40, Noah Slater <nsla...@tumbolia.org> wrote: >> > Are we going to punt on a Windows binary, Dave? >> > >> > On Sun, Jan 15, 2012 at 7:05 PM, Dave Cottlehuber <d...@muse.net.nz> >> wrote: >> > >> >> On 15 January 2012 19:05, Noah Slater <nsla...@tumbolia.org> wrote: >> >> > Bump. Dave? Gonna move without if you don't speak up. :) >> >> >> >> Sorry!! Literally *just* finished looking at this. >> >> >> >> TL;DR - let's roll 1.2.0. >> >> >> >> I don't see any *functional* issues in the failures from the test >> >> suite - attachments are written, and read, correctly. For some as yet >> >> unknown reason the MD5 is different on Windows vs Linux & Mac OS, but >> >> this has been present for some time. It's only turned up as a result >> >> of additional tests applied in COUCHDB-1337. >> >> >> >> The underlying crypto:md5 values are the same, and so is the raw HTTP >> >> data. I am still digging through mochi to where this comes from. >> >> >> >> I don't see any issues for replication - can anybody confirm? This >> >> looks like a dev issue rather than user impacting. >> >> >> >> from 1.1.1_js-1.8.0: >> >> 12> Digest = base64:encode(Digest_Binary). >> >> <<"jeLnIuUvK7d+6gya044lVA==">> >> >> >> >> from 1.2.x: >> >> 8> Digest = base64:encode(Digest_Binary). >> >> <<"jeLnIuUvK7d+6gya044lVA==">> >> >> >> >> A+ >> >> Dave >> >> >>
