incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Problems blocking 1.2.0 release
Date Tue, 07 Feb 2012 11:41:44 GMT

On Feb 6, 2012, at 20:04 , Jan Lehnardt wrote:

> 
> On Feb 4, 2012, at 02:43 , Paul Davis wrote:
> 
>> Doing some traveling but quick thoughts inline:
>> 
>> On Fri, Feb 3, 2012 at 6:29 PM, Noah Slater <nslater@tumbolia.org> 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.
> 
> 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
>> 
>> 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
>> 
>> 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
>> 
>> EXTRA_DIST? Delete?
> 
> File-parity. I'd say we keep it.
> 
>>>> 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.
> 
>>>> 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).


In fact, snappy-stubs-public.h is produced at ./configure time by us, so
we should not ship this.

Cheers
Jan
-- 



>>> 
>>> 
>>> 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
> 


Mime
View raw message