couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Dionne <>
Subject Re: tracking upstream dependencies
Date Sat, 27 Nov 2010 13:06:16 GMT
I think the problem with patches is that they can become unwieldy, .eg. which couch version
plus which set of patches are bundled? There is also the issue of support and bug triage.
A released version has some sort of implicit support offered by the publisher of the release,
whereas a collection of patches are provided by the bundler of the software.

It's not to say patches aren't useful, they are, but they are better employed for exceptional
circumstances and supported by the original publisher. Database vendors often do this.

I haven't followed all the specific dependency issues closely but it strikes me that the state
of development of these various projects makes the "canonical" github approach mentioned earlier

On Nov 27, 2010, at 5:27 AM, Robert Newson wrote:

> I like the Debian approach where they maintain a patchset against a
> pristine upstream tarball.
> I'd particularly like to see the bigcouch variant of couchdb expressed
> that way, it would allow new developers to see where bigcouch diverges
> and it would allow couchdb developers to easily incorporate generally
> useful patches.
> B.
> On Fri, Nov 26, 2010 at 9:25 PM, Dirkjan Ochtman <> wrote:
>> On Fri, Nov 26, 2010 at 22:15, Noah Slater <> wrote:
>>> If we have a checksum, what's the point?
>>> Why not just include the original source the checksum is taken from?
>> The point is keeping very exact track of what the source is. And the
>> point is making it easy for distributors to build without the bundled
>> dependencies. It would be great to also ship an artefact without the
>> bundled deps, but that might be a tad too much work...
>> Cheers,
>> Dirkjan

View raw message