couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: Problems blocking 1.2.0 release
Date Tue, 07 Feb 2012 11:50:25 GMT
On Mon, Feb 6, 2012 at 7:04 PM, Jan Lehnardt <> wrote:
> I'd suggest this looks like we are not using at all
> and we could either delete it or keep to keep file-parity with upstream.
> (file-parity interlude, I'd prefer to keep upstream directories in as
>  much of the original shape as possible to make upgrades more obvious
>  and less error prone)


> >>> Only in 1.2.0/src/mochiweb: mochiweb_request_tests.erl
> >
> > This can probably be deleted outright assuming make check doesn't try
> > and use it (and I don't think it does).
> File-parity. I'd say we keep it.


>>> Only in apache-couchdb-1.2.0/src/snappy:
> >
> > No idea what this business is. An artefact of the snappy build? Just
> delete it?
> gets generated by ./bootstrap and is used by ./configure
> to produce Makefile. We should absolutely keep this and put it in

My error, this is actually fine and doesn't need modification.

> >>> Only in 1.2.0/src/snappy/google-snappy: AUTHORS
> >
> > EXTRA_DIST? Delete?
> File-parity. I'd say we keep it.

My gut tells me we should remove this, but I'm not sure. I can see your
arguments. What have we done in the past? I can't remember. Do any of the
other libraries we bundle include documentation files in the source that we
have removed?

> >>> Only in 1.2.0/src/snappy/google-snappy: COPYING
> >
> > We should look on whether we keep this or not. There's probably ASF
> > guidelines on what to do here. I'm guessing either delete it or add it
> > to NOTICE in the root.
> NOTICE carries the ASF mandated entry for Snappy, so we are covered on
> that end. The other question is file-parity again, I'd say we keep it.

Same point.

> >>> Only in apache-couchdb-1.2.0/src/snappy/google-snappy:
> >>> snappy-stubs-public.h
> >
> > Not sure why this is made by bootstrap. Might be a valid reason, might
> > just need the generation to happen during make instead.
> It looks like it makes some assumptions about types. I'm not the expert
> but assuming the values the packager puts in are the same for everybody
> is dangerous at best. So yes, I agree, a Make-ification is in order.
> Can we fix this upstream (a brief search didn't suggest any existing
> solutions).

Per your follow up, we should not ship this. Agreed.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message