> On 15 Apr 2016, at 14:38, Paul J Davis <[email protected]> wrote: > > > >> On Apr 15, 2016, at 3:13 AM, Jan Lehnardt <[email protected]> wrote: >> >> >>> On 14 Apr 2016, at 23:11, Joan Touzet <[email protected]> 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" <[email protected]> >>>> To: [email protected], "Joan Touzet" <[email protected]> >>>> 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 <[email protected]> >>>> 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" <[email protected]> >>>>>> To: [email protected] >>>>>> 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 >>>>>> <[email protected]> >>>>>> 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/
