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 29F959B04 for ; Sat, 4 Feb 2012 01:44:41 +0000 (UTC) Received: (qmail 29770 invoked by uid 500); 4 Feb 2012 01:44:40 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 29651 invoked by uid 500); 4 Feb 2012 01:44:39 -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 29624 invoked by uid 99); 4 Feb 2012 01:44:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 04 Feb 2012 01:44:39 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.212.52 as permitted sender) Received: from [209.85.212.52] (HELO mail-vw0-f52.google.com) (209.85.212.52) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 04 Feb 2012 01:44:33 +0000 Received: by vbih1 with SMTP id h1so3970176vbi.11 for ; Fri, 03 Feb 2012 17:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=9iMNSfEcF56yHXDxdVa/oKoxjlsRaZkSfEndB+Hzeho=; b=mCKlr6MruxCSjN1uUAQoCUxfnpodRRi3OSLd3q0Qi7PU5W6hD1jaWQyPNjJAC9sI1T EIgFMESrXMLCYjz/zaKq4wgCyU7Lr2ryr4QpRed8hWSNfzBNMF6WB6tKVpkAfmskG8u1 xMfBphmcfOwJT3CWq/wq3nF1eqh3TFBPAe0/4= Received: by 10.52.22.166 with SMTP id e6mr4567489vdf.5.1328319852296; Fri, 03 Feb 2012 17:44:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.7.208 with HTTP; Fri, 3 Feb 2012 17:43:32 -0800 (PST) In-Reply-To: References: From: Paul Davis Date: Fri, 3 Feb 2012 20:43:32 -0500 Message-ID: Subject: Re: Problems blocking 1.2.0 release To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org Doing some traveling but quick thoughts inline: On Fri, Feb 3, 2012 at 6:29 PM, Noah Slater wrote: > Hello, > > I have a 1.2.0 release ready to go, but there are a few problems that need > fixing before I am prepared to ship. > > Comparing our source to the release artefact, I get: > > Only in 1.2.0/src/mochiweb: mochiweb.app.src IIRC, I think I noticed that we're not generating a mochiweb.app from this file. It needs to be there and we need to generate it and there's a pattern. Just needs a rule in the make file and an EXTRA_DIST entry for the .app I think. >> 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). >> 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? >> Only in 1.2.0/src/snappy/google-snappy: AUTHORS EXTRA_DIST? Delete? >> 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. >> 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. > > For lines that start: > > Only in 1.2.0 > > > The only time this should ever happen is when the file is used by the > bootstrap process, or Git, and can be discarded after bootstrapping. > Clearly, none of these files pass that requirement. Which means that we > should be shipping them in the source tarball. Probably by adding them to > EXTRA_DIST or something. > > For lines that start: > > Only in apache-couchdb-1.2.0 > > > The only time this should ever happen is when the file is created by the > bootstrap process, or need to be made on the assumption that our users will > not be able to make them, as is the case for our man pages. Clearly, none > of these files pass that requirement. Now, I checked the snappy makefile, > and it looks like we're shipping these generated files on purpose, which is > very strange. > > So, over to you, Paul, I guess. Want to weigh in on these? They need fixing > on master as well as the release branch. > > Thanks, > > N