couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: On dependency management and CI issues associated with it
Date Fri, 15 Apr 2016 19:05:35 GMT
Ah, that sounds like a good approach to me.

On Fri, Apr 15, 2016 at 11:39 AM, Jan Lehnardt <jan@apache.org> wrote:
>
>> On 15 Apr 2016, at 14:38, Paul J Davis <paul.joseph.davis@gmail.com> wrote:
>>
>>
>>
>>> On Apr 15, 2016, at 3:13 AM, Jan Lehnardt <jan@apache.org> wrote:
>>>
>>>
>>>> On 14 Apr 2016, at 23:11, Joan Touzet <wohali@apache.org> wrote:
>>>>
>>>> Based on this information, are we in violation of ASF requirements? Can
>>>> anyone clarify for me what we actually need to be doing here?
>>>
>>> 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.
>>>
>>
>> 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.
>
> 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’d prefer our end-users to
having to run `npm install` on CouchDB install time. We can get “around” 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
> --
>
>
>>
>>> The question of whether to have a “safe copy“ to be ensured against
>>> suddenly disappearing upstream is entirely* up to the project, but not
>>> ASF policy.
>>>
>>> *upstream dependencies that have dual licensing that includes a GPL
>>> flavour or other incompatible license[1] can’t be mirrored on ASF
>>> source control and distribution servers (that’s why we don’t mirror
>>> SpiderMonkey or Erlang (although we could do Erlang now, that they
>>> switched to ASF 2, but I would not suggest we do this).
>>>
>>> [1]: http://www.apache.org/legal/resolved.html#category-x
>>>
>>> * * *
>>>
>>> Personally, with npm’s new unpublish policy[2], I’m okay with having
>>> our dependencies there.
>>>
>>> Because of the deep dependency tree, we should be very diligent about
>>> not accidentally including category-x licensed modules. I’m sure we
>>> can automate this into a npm postinstall script, so we know as soon
>>> as possible.
>>>
>>> At the very least, we need an audit prior to any release.
>>>
>>> [2]: http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy
>>>
>>> Best
>>> Jan
>>> --
>>>
>>>
>>>>
>>>> -Joan
>>>>
>>>> ----- 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
>>>>>
>>>>> Hi Joan,
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>> Cheers
>>>>> Garren
>>>>>
>>>>> On Wed, Apr 13, 2016 at 11:29 PM, Joan Touzet <wohali@apache.org>
>>>>> wrote:
>>>>>
>>>>>> 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?
>>>>>>
>>>>>> -Joan
>>>>>>
>>>>>> ----- 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
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> --
>>>>>>> ,,,^..^,,,
>>>
>>> --
>>> Professional Support for Apache CouchDB:
>>> https://neighbourhood.ie/couchdb-support/
>>>
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
>

Mime
View raw message