Ah, that sounds like a good approach to me.
On Fri, Apr 15, 2016 at 11:39 AM, Jan Lehnardt <j...@apache.org> wrote: > >> On 15 Apr 2016, at 14:38, Paul J Davis <paul.joseph.da...@gmail.com> wrote: >> >> >> >>> On Apr 15, 2016, at 3:13 AM, Jan Lehnardt <j...@apache.org> wrote: >>> >>> >>>> On 14 Apr 2016, at 23:11, Joan Touzet <woh...@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" <gar...@apache.org> >>>>> To: dev@couchdb.apache.org, "Joan Touzet" <woh...@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 <woh...@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" <kxe...@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 >>>>>>> <rnew...@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/ >
