From dev-return-20484-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Tue Feb 7 12:05:53 2012 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 342749E1D for ; Tue, 7 Feb 2012 12:05:53 +0000 (UTC) Received: (qmail 96075 invoked by uid 500); 7 Feb 2012 12:05:52 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 95973 invoked by uid 500); 7 Feb 2012 12:05:51 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 95964 invoked by uid 99); 7 Feb 2012 12:05:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Feb 2012 12:05:51 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [80.244.253.218] (HELO mail.traeumt.net) (80.244.253.218) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Feb 2012 12:05:45 +0000 Received: from rose.local (pD4B88CBB.dip.t-dialin.net [212.184.140.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.traeumt.net (Postfix) with ESMTPSA id 78A703CA5E for ; Tue, 7 Feb 2012 13:05:24 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) Subject: Re: Problems blocking 1.2.0 release From: Jan Lehnardt In-Reply-To: Date: Tue, 7 Feb 2012 13:05:24 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: To: dev@couchdb.apache.org X-Mailer: Apple Mail (2.1251.1) On Feb 7, 2012, at 12:50 , Noah Slater wrote: > On Mon, Feb 6, 2012 at 7:04 PM, Jan Lehnardt 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? I don't think we have a strict policy (aside from licensing and NOTICE guidelines) and whoever was responsible for bringing in a library did whatever they felt like. I just know from updating a few libraries to newer versions over time that being diligent about pruning files strictly not needed made the update process a bit more tedious. Hence my suggestion to make it easier for future us's. Cheers Jan -- > > >>>>> 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.