Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: On dependency management and CI issues associated with it
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: <EBB5E5E3-FA6B-4CB5-961B-E032515A1D6F@gmail.com>
Date: Fri, 15 Apr 2016 18:39:54 +0200
Cc: Joan Touzet <wohali@apache.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <66ECFABB-E6C3-4A23-8EA4-D177F460AC48@apache.org>
References: <30371824.734.1460668306614.JavaMail.Joan@RITA>
 <0F97C63F-3772-49AA-BD88-D6284A9B9D41@apache.org>
 <EBB5E5E3-FA6B-4CB5-961B-E032515A1D6F@gmail.com>
To: dev@couchdb.apache.org


> On 15 Apr 2016, at 14:38, Paul J Davis <paul.joseph.davis@gmail.com> =
wrote:
>=20
>=20
>=20
>> On Apr 15, 2016, at 3:13 AM, Jan Lehnardt <jan@apache.org> wrote:
>>=20
>>=20
>>> On 14 Apr 2016, at 23:11, Joan Touzet <wohali@apache.org> wrote:
>>>=20
>>> Based on this information, are we in violation of ASF requirements? =
Can
>>> anyone clarify for me what we actually need to be doing here?
>>=20
>> There is no such policy. We are also not bundling SpiderMonkey or =
Erlang
>> either. Neither do any of the Java projects bundle e.g. OpenJDK.
>>=20
>=20
> My understanding is that anything included in an ASF release tarball =
must be in ASF source control which is why we mirror mochiweb but not =
Erlang.

> There are also rules about downloading things to build ASF projects =
and the Java/Maven communities should have this info. Given that Erlang =
hasn't had a real package thing until semi recently its not something =
I've spent time figuring out.=20

Good subtlety! I remember a vigorous discussion about the maven stuff, =
we should check that out.

In the meantime, this only makes things inconvenient as we=E2=80=99d =
prefer our end-users to having to run `npm install` on CouchDB install =
time. We can get =E2=80=9Caround=E2=80=9D this by making the source =
tarball our Release, but recommend end-user recommend a tarball that =
includes the deps, but not make it that the official Release, like we do =
with the Mac build.

Best
Jan
--


>=20
>> The question of whether to have a =E2=80=9Csafe copy=E2=80=9C to be =
ensured against
>> suddenly disappearing upstream is entirely* up to the project, but =
not
>> ASF policy.
>>=20
>> *upstream dependencies that have dual licensing that includes a GPL
>> flavour or other incompatible license[1] can=E2=80=99t be mirrored on =
ASF
>> source control and distribution servers (that=E2=80=99s why we =
don=E2=80=99t mirror
>> SpiderMonkey or Erlang (although we could do Erlang now, that they
>> switched to ASF 2, but I would not suggest we do this).
>>=20
>> [1]: http://www.apache.org/legal/resolved.html#category-x
>>=20
>> * * *
>>=20
>> Personally, with npm=E2=80=99s new unpublish policy[2], I=E2=80=99m =
okay with having
>> our dependencies there.
>>=20
>> Because of the deep dependency tree, we should be very diligent about
>> not accidentally including category-x licensed modules. I=E2=80=99m =
sure we
>> can automate this into a npm postinstall script, so we know as soon
>> as possible.
>>=20
>> At the very least, we need an audit prior to any release.
>>=20
>> [2]: =
http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy
>>=20
>> Best
>> Jan
>> --
>>=20
>>=20
>>>=20
>>> -Joan
>>>=20
>>> ----- Original Message -----
>>>> From: "Garren Smith" <garren@apache.org>
>>>> To: dev@couchdb.apache.org, "Joan Touzet" <wohali@apache.org>
>>>> Sent: Thursday, April 14, 2016 2:43:10 AM
>>>> Subject: Re: On dependency management and CI issues associated with =
it
>>>>=20
>>>> Hi Joan,
>>>>=20
>>>> Good point. Until about a week ago we use to keep all our
>>>> dependencies in
>>>> our repo. But we have just switched to webpack which allows us to
>>>> manage
>>>> our dependencies via npm (in case you are wondering, we don't =
depend
>>>> on
>>>> leftpad directly). So some of them are in our repo but the majority
>>>> are
>>>> downloaded and then bundled.
>>>>=20
>>>>=20
>>>> Cheers
>>>> Garren
>>>>=20
>>>> On Wed, Apr 13, 2016 at 11:29 PM, Joan Touzet <wohali@apache.org>
>>>> wrote:
>>>>=20
>>>>> Garren, correct me if I'm wrong but Fauxton depends on a large
>>>>> number
>>>>> of JS dependencies that we don't keep copies of, correct? Or is it
>>>>> just
>>>>> for the build process?
>>>>>=20
>>>>> -Joan
>>>>>=20
>>>>> ----- Original Message -----
>>>>>> From: "Alexander Shorin" <kxepal@gmail.com>
>>>>>> To: dev@couchdb.apache.org
>>>>>> Sent: Wednesday, April 13, 2016 2:08:20 PM
>>>>>> Subject: Re: On dependency management and CI issues associated
>>>>>> with it
>>>>>>=20
>>>>>> On Wed, Apr 13, 2016 at 8:39 PM, Robert Newson
>>>>>> <rnewson@apache.org>
>>>>>> wrote:
>>>>>>> It's a thread derail but this notion that we're being "fairly
>>>>>>> rude"
>>>>>>> needs resolving. It might be lost to history now but we got
>>>>>>> here,
>>>>>>> I think, with the best intentions of ensuring all the code that
>>>>>>> appears in couchdb can be traced back to code hosted at asf. Is
>>>>>>> it
>>>>>>> a concrete requirement? I honestly forget but I thought so.
>>>>>>=20
>>>>>> Yes, that's the answer why. If one day mochiweb owner will decide
>>>>>> to
>>>>>> drop his github repo, we shouldn't be leave with broken builds.
>>>>>> See
>>>>>> leftpad story as well. Initially, that requirement seems
>>>>>> redundant,
>>>>>> but recent npm drama showed that it has a huge point. Also there
>>>>>> are
>>>>>> some legal bits about.
>>>>>>=20
>>>>>> --
>>>>>> ,,,^..^,,,
>>=20
>> --=20
>> Professional Support for Apache CouchDB:
>> https://neighbourhood.ie/couchdb-support/
>>=20

--=20
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/