On 26 Nov 2010, at 15:23, Peter Lemenkov wrote: > Hello > > 2010/11/26 Jan Lehnardt <[email protected]>: > >> 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 --
