On Mon, Feb 6, 2012 at 7:04 PM, Jan Lehnardt <[email protected]> wrote: > > I'd suggest this looks like we are not using mochiweb.app.src 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)
Keep. > >>> 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. Keep. >>> Only in apache-couchdb-1.2.0/src/snappy: Makefile.in > > > > No idea what this business is. An artefact of the snappy build? Just > delete it? > > Makefile.in gets generated by ./bootstrap and is used by ./configure > to produce Makefile. We should absolutely keep this and put it in > EXTRA_DIST. 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.
