couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: [VOTE] Apache CouchDB 1.0.2 release, Round 1
Date Fri, 26 Nov 2010 14:57:39 GMT

On 26 Nov 2010, at 15:23, Peter Lemenkov wrote:

> Hello
> 
> 2010/11/26 Jan Lehnardt <jan@apache.org>:
> 
>> We always patch Mochiweb to fit our needs that are divergent from the
>> upstream project. It isn't safe to assume an independent cut of Mochiweb
>> will just work.
> 
> Well, it isn't even safe to assume that it will work on an arbitrary
> system with different set of underlying libraries and tools. So we
> just play for the stable API/ABI interfaces. Shipping internally a
> small set of libraries isn't enough - you need to ship js, libicu,
> erlang and so on.

Of course, the point I was making is that we do break* said interface
deliberately.


>> e.g. we're changing the default handling of encoding integers in mochijson2
>> among other things.
> 
> Fortunately it's not very diverged from upstream - it just too old. I
> re-checked (as I did every couchdb release since 0.10.2) what was
> added in CouchDB internal copy - I don't see what changes from CouchDB
> copy are  still missing in upstream repository (perhaps someone from
> Mochi is monitoring your work and quickly applies changes if any).

We usually propose patches upstream where they get reviewed. Historically
we have a pretty good acceptance rate.

* I did check back with the integer issue that I though didn't make it but
it seems latest mochijson2.erl has that patch, so sorry for the noise.

Robert is currently checking for other differences.


>> I'd strongly suggest to not build a package that is seemingly like our
>> release but has subtle differences or bugs.
> 
> It hasn't any known bugs related to my changes (i mean I wasn't aware
> of them - not that they doesn't exist). So that's a pure speculation.
> On the other hand your copy of mochiweb does contains known defects
> already fixed in upstream. Not sure whether they affect CouchDB
> operation though.

There's plenty of defects we know of that ship with stable releases.
The issue that worries us here is that you may introduce subtle bugs
due to your packaging policy that ends up being an unhappy situation
for CouchDB users.

This is not a passing the blame situation, I understand that the
priorities of a package manager are quite different from a project.
I just want to make sure you understand my position. Besides, you're
quite the opposite than most distributions which ship out of date
dependencies that we can't rely on, so the forward/parity is rather
unique (at least for me :).

That said, your work is highly appreciated and we hope we can make
it easier for you down the road.

I wonder what the best solution here is. The problem with updating
to the latest Mochiweb right before a release is that subtle issues
don't have time surfacing in trunk. To ensure stable releases we
should be conservative with updates (modulo critical bug fixes of
course) or upstream libraries. How can we best ensure to keep them
up to date enough while not compromising a release's stability?

Cheers
Jan
-- 











Mime
View raw message