Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
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 <jan@apache.org>
In-Reply-To: 
 <CAJ_m3YBR88uRSLH7zV9evQBHzirNWWiXtgVGiLdFeaVepOx2dQ@mail.gmail.com>
Date: Mon, 6 Feb 2012 20:04:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <EC76B561-52F0-4E62-884E-843F2055BDB9@apache.org>
References: 
 <CA+Y+447auJb7GVn0cskSQpKZzEX-i811d6asMrJaUFVKeL+C6w@mail.gmail.com>
 <CAJ_m3YBR88uRSLH7zV9evQBHzirNWWiXtgVGiLdFeaVepOx2dQ@mail.gmail.com>
To: dev@couchdb.apache.org


On Feb 4, 2012, at 02:43 , Paul Davis wrote:

> Doing some traveling but quick thoughts inline:
>=20
> On Fri, Feb 3, 2012 at 6:29 PM, Noah Slater <nslater@tumbolia.org> =
wrote:
>> Hello,
>>=20
>> 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.
>>=20
>> Comparing our source to the release artefact, I get:
>>=20
>> Only in 1.2.0/src/mochiweb: mochiweb.app.src
>=20
> 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.

Makefile.am has:

   %.app: %.app.in
	cp $< $@

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)

>>> Only in 1.2.0/src/mochiweb: mochiweb_request_tests.erl
>=20
> 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: Makefile.in
>=20
> 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.

>>> Only in 1.2.0/src/snappy/google-snappy: AUTHORS
>=20
> EXTRA_DIST? Delete?

File-parity. I'd say we keep it.

>>> Only in 1.2.0/src/snappy/google-snappy: COPYING
>=20
> 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.

>>> Only in apache-couchdb-1.2.0/src/snappy/google-snappy:
>>> snappy-stubs-public.h
>=20
> 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).

Cheers
Jan
--=20


>=20
>>=20
>> For lines that start:
>>=20
>> Only in 1.2.0
>>=20
>>=20
>> 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.
>>=20
>> For lines that start:
>>=20
>> Only in apache-couchdb-1.2.0
>>=20
>>=20
>> 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.
>>=20
>> So, over to you, Paul, I guess. Want to weigh in on these? They need =
fixing
>> on master as well as the release branch.
>>=20
>> Thanks,
>>=20
>> N