Re: make

[Joan Touzet]

Windows port. If the test suite is finally stable we'll do another
pass of getting this to work - sans the Win 10 bash stuff since a)
that's still in private release and b) Win 10 stinks.

-Joan

- Original Message -
> From: "Jan Lehnardt" 
> To: dev@couchdb.apache.org
> Sent: Friday, April 15, 2016 4:48:29 PM
> Subject: Re: make
> 
> What else is missing for 2.0? If nothing/not much, I'd like to get
> first 2.0.0 release candidates out next week.
> 
> It's time to bring out your pet features/bug fixes ;)
> 
> Jan
> --
> 
> > On 15 Apr 2016, at 18:31, Jan Lehnardt  wrote:
> > 
> > As promised: https://github.com/apache/couchdb/pull/402
> > 
> > Little issue with Fauxton, would love help from the team <3
> > 
> > Best
> > Jan
> > --
> > 
> >> On 30 Mar 2016, at 21:57, Jan Lehnardt  wrote:
> >> 
> >> Hey all,
> >> 
> >> last year I endeavoured to make the 2.0 build system to behave as
> >> close to 1.x as possible.
> >> 
> >> We’re 80% there, but the remaining 80% prove hard, of course.
> >> Without going too much into the details, the missing parts are
> >> the integration with all the different operating systems. Stuff
> >> that takes years to get right (even with autotools in 1.x it took
> >> us quite some time).
> >> 
> >> To keep it short: I don’t want to hold up 2.0 for this work. It
> >> can be easily (re-)added later, and the intermediate solution
> >> allows us to ship 2.0 sooner (yay).
> >> 
> >> My current plan is to have `./configure && make` produce a
> >> directory `./apache-couchdb-` that includes a full
> >> CouchDB build, Fauxton, Docs, etc. that can be moved into the OS
> >> anywhere (say `/usr/local`) and run from there, and everything:
> >> logs, data files, sources, ini files, are in that directory, and
> >> there is no way to move them out (maybe via symlinks, but I don’t
> >> care ;) into a standard file system layout (config files under
> >> [/usr/local]/etc, data files into [/usr/local]/var/lib etc. There
> >> won’t be a `make install` (maybe a dummy that prints an
> >> explanation of how to do the install, and why the target isn’t
> >> there).
> >> 
> >> This shouldn’t be a lot of work and I’ll try to work on this asap.
> >> 
> >> Let me know what you think!
> >> 
> >> Best
> >> Jan
> >> --
> >> Professional Support for Apache CouchDB:
> >> https://neighbourhood.ie/couchdb-support/
> > 
> > --
> > Professional Support for Apache CouchDB:
> > https://neighbourhood.ie/couchdb-support/
> > 
> 
> 

Re: make

[Jan Lehnardt]

What else is missing for 2.0? If nothing/not much, I'd like to get first 2.0.0 
release candidates out next week.

It's time to bring out your pet features/bug fixes ;)

Jan
--

> On 15 Apr 2016, at 18:31, Jan Lehnardt  wrote:
> 
> As promised: https://github.com/apache/couchdb/pull/402
> 
> Little issue with Fauxton, would love help from the team <3
> 
> Best
> Jan
> --
> 
>> On 30 Mar 2016, at 21:57, Jan Lehnardt  wrote:
>> 
>> Hey all,
>> 
>> last year I endeavoured to make the 2.0 build system to behave as close to 
>> 1.x as possible.
>> 
>> We’re 80% there, but the remaining 80% prove hard, of course. Without going 
>> too much into the details, the missing parts are the integration with all 
>> the different operating systems. Stuff that takes years to get right (even 
>> with autotools in 1.x it took us quite some time).
>> 
>> To keep it short: I don’t want to hold up 2.0 for this work. It can be 
>> easily (re-)added later, and the intermediate solution allows us to ship 2.0 
>> sooner (yay).
>> 
>> My current plan is to have `./configure && make` produce a directory 
>> `./apache-couchdb-` that includes a full CouchDB build, Fauxton, 
>> Docs, etc. that can be moved into the OS anywhere (say `/usr/local`) and run 
>> from there, and everything: logs, data files, sources, ini files, are in 
>> that directory, and there is no way to move them out (maybe via symlinks, 
>> but I don’t care ;) into a standard file system layout (config files under 
>> [/usr/local]/etc, data files into [/usr/local]/var/lib etc. There won’t be a 
>> `make install` (maybe a dummy that prints an explanation of how to do the 
>> install, and why the target isn’t there).
>> 
>> This shouldn’t be a lot of work and I’ll try to work on this asap.
>> 
>> Let me know what you think!
>> 
>> Best
>> Jan
>> -- 
>> Professional Support for Apache CouchDB:
>> https://neighbourhood.ie/couchdb-support/
> 
> -- 
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
> 

Re: Adam Kocoloski is now an IBM Fellow

[Joan Touzet]

Congrats!

- Original Message -
> From: "Jan Lehnardt" 
> To: "dev@couchdb.apache.org Developers" 
> Sent: Friday, April 15, 2016 4:50:10 AM
> Subject: Adam Kocoloski is now an IBM Fellow
> 
> Hey all,
> 
> our own Adam made IBM Fellow! He’s now one of only 267* individuals
> who’ve been awarded this honour for their contributions to IBM and
> computing in general:
> 
>   http://www.ibm.com/ibm/ideasfromibm/us/ibm_fellows/2016/
> 
> Congratulations Adam, very proud to have you on the team :)
> 
> Best
> Jan
> --
> * this is only slightly less than the number of git repos
>   we now manage.

Re: On dependency management and CI issues associated with it

[Paul Davis]

Ah, that sounds like a good approach to me.

On Fri, Apr 15, 2016 at 11:39 AM, Jan Lehnardt  wrote:
>
>> On 15 Apr 2016, at 14:38, Paul J Davis  wrote:
>>
>>
>>
>>> On Apr 15, 2016, at 3:13 AM, Jan Lehnardt  wrote:
>>>
>>>
 On 14 Apr 2016, at 23:11, Joan Touzet  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" 
> To: dev@couchdb.apache.org, "Joan Touzet" 
> 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 
> 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" 
>>> 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
>>> 
>>> 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:
>>> 

Re: On dependency management and CI issues associated with it

[Jan Lehnardt]

> On 15 Apr 2016, at 14:38, Paul J Davis  wrote:
> 
> 
> 
>> On Apr 15, 2016, at 3:13 AM, Jan Lehnardt  wrote:
>> 
>> 
>>> On 14 Apr 2016, at 23:11, Joan Touzet  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" 
 To: dev@couchdb.apache.org, "Joan Touzet" 
 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 
 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" 
>> 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
>> 
>> 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/

Re: make

[Jan Lehnardt]

As promised: https://github.com/apache/couchdb/pull/402

Little issue with Fauxton, would love help from the team <3

Best
Jan
--

> On 30 Mar 2016, at 21:57, Jan Lehnardt  wrote:
> 
> Hey all,
> 
> last year I endeavoured to make the 2.0 build system to behave as close to 
> 1.x as possible.
> 
> We’re 80% there, but the remaining 80% prove hard, of course. Without going 
> too much into the details, the missing parts are the integration with all the 
> different operating systems. Stuff that takes years to get right (even with 
> autotools in 1.x it took us quite some time).
> 
> To keep it short: I don’t want to hold up 2.0 for this work. It can be easily 
> (re-)added later, and the intermediate solution allows us to ship 2.0 sooner 
> (yay).
> 
> My current plan is to have `./configure && make` produce a directory 
> `./apache-couchdb-` that includes a full CouchDB build, Fauxton, 
> Docs, etc. that can be moved into the OS anywhere (say `/usr/local`) and run 
> from there, and everything: logs, data files, sources, ini files, are in that 
> directory, and there is no way to move them out (maybe via symlinks, but I 
> don’t care ;) into a standard file system layout (config files under 
> [/usr/local]/etc, data files into [/usr/local]/var/lib etc. There won’t be a 
> `make install` (maybe a dummy that prints an explanation of how to do the 
> install, and why the target isn’t there).
> 
> This shouldn’t be a lot of work and I’ll try to work on this asap.
> 
> Let me know what you think!
> 
> Best
> Jan
> -- 
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
> 

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

Re: On dependency management and CI issues associated with it

[Paul J Davis]

> On Apr 15, 2016, at 3:13 AM, Jan Lehnardt  wrote:
> 
> 
>> On 14 Apr 2016, at 23:11, Joan Touzet  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. 

> 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" 
>>> To: dev@couchdb.apache.org, "Joan Touzet" 
>>> 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 
>>> 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" 
> 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
> 
> 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/
> 

Re: Adam Kocoloski is now an IBM Fellow

[Kyle Snavely]

You rock, Adam!

On Fri, Apr 15, 2016 at 6:52 AM, Garren Smith  wrote:

> Congrats Adam. That is really awesome.
>
> On Friday, 15 April 2016, Andy Wenk  wrote:
>
> > Wow - that’s awesome - congrats Adam ;-)
> >
> > All the best
> >
> > Andy
> >
> > --
> > Andy Wenk
> > Hamburg - Germany
> > RockIt!
> >
> > GPG public key:
> > https://pgp.mit.edu/pks/lookup?op=get=0x4F1D0C59BC90917D
> >
> >
> >
> >
> > > On 15 Apr 2016, at 10:58, Johs Ensby >
> > wrote:
> > >
> > > Congratulations, Adam
> > >
> > > I'm very proud that I met you at Cloudant back in 2009
> > > johs
> > >
> > >> On 15. apr. 2016, at 10.50, Jan Lehnardt  >
> > wrote:
> > >>
> > >> Hey all,
> > >>
> > >> our own Adam made IBM Fellow! He’s now one of only 267* individuals
> > >> who’ve been awarded this honour for their contributions to IBM and
> > >> computing in general:
> > >>
> > >> http://www.ibm.com/ibm/ideasfromibm/us/ibm_fellows/2016/
> > >>
> > >> Congratulations Adam, very proud to have you on the team :)
> > >>
> > >> Best
> > >> Jan
> > >> --
> > >> * this is only slightly less than the number of git repos
> > >> we now manage.
> > >
> >
> >
>

Re: Adam Kocoloski is now an IBM Fellow

[Garren Smith]

Congrats Adam. That is really awesome.

On Friday, 15 April 2016, Andy Wenk  wrote:

> Wow - that’s awesome - congrats Adam ;-)
>
> All the best
>
> Andy
>
> --
> Andy Wenk
> Hamburg - Germany
> RockIt!
>
> GPG public key:
> https://pgp.mit.edu/pks/lookup?op=get=0x4F1D0C59BC90917D
>
>
>
>
> > On 15 Apr 2016, at 10:58, Johs Ensby >
> wrote:
> >
> > Congratulations, Adam
> >
> > I'm very proud that I met you at Cloudant back in 2009
> > johs
> >
> >> On 15. apr. 2016, at 10.50, Jan Lehnardt >
> wrote:
> >>
> >> Hey all,
> >>
> >> our own Adam made IBM Fellow! He’s now one of only 267* individuals
> >> who’ve been awarded this honour for their contributions to IBM and
> >> computing in general:
> >>
> >> http://www.ibm.com/ibm/ideasfromibm/us/ibm_fellows/2016/
> >>
> >> Congratulations Adam, very proud to have you on the team :)
> >>
> >> Best
> >> Jan
> >> --
> >> * this is only slightly less than the number of git repos
> >> we now manage.
> >
>
>

Re: Adam Kocoloski is now an IBM Fellow

[Andy Wenk]

Wow - that’s awesome - congrats Adam ;-)

All the best

Andy

--
Andy Wenk
Hamburg - Germany
RockIt!

GPG public key: https://pgp.mit.edu/pks/lookup?op=get=0x4F1D0C59BC90917D




> On 15 Apr 2016, at 10:58, Johs Ensby  wrote:
> 
> Congratulations, Adam
> 
> I'm very proud that I met you at Cloudant back in 2009
> johs
> 
>> On 15. apr. 2016, at 10.50, Jan Lehnardt  wrote:
>> 
>> Hey all,
>> 
>> our own Adam made IBM Fellow! He’s now one of only 267* individuals
>> who’ve been awarded this honour for their contributions to IBM and
>> computing in general:
>> 
>> http://www.ibm.com/ibm/ideasfromibm/us/ibm_fellows/2016/
>> 
>> Congratulations Adam, very proud to have you on the team :)
>> 
>> Best
>> Jan
>> --
>> * this is only slightly less than the number of git repos
>> we now manage.
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Adam Kocoloski is now an IBM Fellow

[Johs Ensby]

Congratulations, Adam

I'm very proud that I met you at Cloudant back in 2009
johs

> On 15. apr. 2016, at 10.50, Jan Lehnardt  wrote:
> 
> Hey all,
> 
> our own Adam made IBM Fellow! He’s now one of only 267* individuals
> who’ve been awarded this honour for their contributions to IBM and
> computing in general:
> 
>  http://www.ibm.com/ibm/ideasfromibm/us/ibm_fellows/2016/
> 
> Congratulations Adam, very proud to have you on the team :)
> 
> Best
> Jan
> --
> * this is only slightly less than the number of git repos
>  we now manage.

Adam Kocoloski is now an IBM Fellow

[Jan Lehnardt]

Hey all,

our own Adam made IBM Fellow! He’s now one of only 267* individuals
who’ve been awarded this honour for their contributions to IBM and
computing in general:

  http://www.ibm.com/ibm/ideasfromibm/us/ibm_fellows/2016/

Congratulations Adam, very proud to have you on the team :)

Best
Jan
--
* this is only slightly less than the number of git repos
  we now manage.

Re: On dependency management and CI issues associated with it

[Jan Lehnardt]

Hey all, love the discussion! :)

I’ve identified these issues in this thread:

1. multi-repo vs. mono-repo
 - with the sub-issues of how mono the repo should be
 - and how to get tooling and process going specifically

2. keeping safe copies of upstream dependencies to avoid left-padding
 - with the sub-issue of not being able to do this for every single one
   because of licensing.

Let’s try to keep those separate :)


* * * Summary

As for 1, I think we have a rough consensus about going back to some form
of mono-repo. I don’t think anyone disagrees with keeping fauxton and the
docs in separate repos as well, same with nano and nmo, essentially
everything “non-core Erlang”.

The open question then is do we bundle *everything* else together, including
the Erlang apps that are usable standalone as outlined by Paul, or fold them
in. I think we have to further separate these by “developed by us” and “forks
from upstream“ like mochiweb, ibrowse and jiffy (although, nice overlap here :).

2. we should be discussing. Which deps are we afraid of going away, what should
our policy be, etc? But let’s spin this out in a new thread. If you want to
reply to this, please choose a new Subject line.


* * * Opinion

From a “this sounds neat”-perspective, I’d prefer these three tiers:

1. one repo for all ASF-developed CouchDB bits that are not reasonably different
   Erlang apps (couch-replicator, chttpd, etc)*
2. one repo each for ASF-developed CouchDB bits that are reasonably used in
   other projects (khash, b64url, snappy, etc)
3. one repo each for upstream forks.

* although they should continue to be separated in src/subdirs, and not all in
src/couchdb as we did in 1.x.

My assumption is that category 2 deps are usually not the ones causing trouble
in today’s development flow (please correct me if I’m wrong).

And I don’t know if development tooling gets any easier if we keep some things
separate and others not, but if at all possible, I think the above is the most
sensible.

I don’t have too much experience with git subtree, but the docs are surely
not beginner friendly, but I’m sure with a nice dev guide, we should be able
to follow along.

Best
Jan
-- 


> On 13 Apr 2016, at 19:42, Robert Newson  wrote:
> 
> As for the separation we have enforcing good practices, I don't buy it. 
> 
> I don't think it will be difficult to prevent the kind of coupling you (and 
> I) would find troubling.  It might even be easier to see if a single commit 
> touches multiple src/ subdirectories that might be missed when reviewing 
> separate pr's. At least, I'm not sure I could slide a credit card between 
> them. 
> 
>> On 13 Apr 2016, at 17:44, Adam Kocoloski  wrote:
>> 
>> 
>>> On Apr 13, 2016, at 12:30 PM, Alexander Shorin  wrote:
>>> 
>>> Hi Paul!
>>> 
>>> Thanks for great input!
>>> 
 On Wed, Apr 13, 2016 at 7:11 PM, Paul Davis  
 wrote:
 If anyone has a strong objection to a monolithic Erlang repo I'd like
 to hear it. Otherwise I may work up a lengthier and more thorough
 proposal for dev@ to consider consolidating all of these repositories
 for sanity and profit.
>>> 
>>> It's hard to object against that since this actually solves a lot of
>>> problems solution of which will require more work to do and still will
>>> leave a place for mistakes or require quite specific toolchain to
>>> work.
>>> 
>>> Making our current repos design work right will require even more work to 
>>> apply.
>>> 
>>> So, for point of time/resources/usability there is no much choice.
>>> 
>>> I think folding the "Erlang repos developed by ASF" list will solve
>>> most part of the problems. However, I think it worth to keep these
>>> apps in own repos:
>>> - rexi
>>> - b64url
>>> - config
>>> - snappy
>>> - khash
>>> - ets-lru
>>> - twig (why we still need it?)
>>> 
>>> As they could be reused outside and they shouldn't involve any
>>> dependencies with other couch modules by design. Everyone else may
>>> stand on where they are.
>>> 
>>> P.S. I'm not sure if git-subtree will not introduce more new problems
>>> as it's quite tricky thing to live with it.
>>> 
>>> --
>>> ,,,^..^,,,
>> 
>> +1 Alex. I disagree that “one Erlang repo” is the goal. Erlang is just 
>> starting to get better support for package managers and the like, and it’d 
>> be a shame to miss out on opportunities for adoption of and contribution to 
>> general-purpose libraries like config, rexi, khash or ets-lru by bundling 
>> them into a repo that doesn’t look or feel like an idiomatic Erlang repo. 
>> And at any rate I certainly hope no one is proposing to copy/paste other 
>> upstream deps into one repo — the current practice of hosting a fork that 
>> doesn’t get recognized as a fork in GitHub is already fairly rude behavior 
>> on our part.
>> 
>> I’ll agree that some of the repo creation has gotten a bit out of control. I 
>> believe _some_ of the friction is 

Re: On dependency management and CI issues associated with it

[Jan Lehnardt]

> On 14 Apr 2016, at 23:11, Joan Touzet  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.

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" 
>> To: dev@couchdb.apache.org, "Joan Touzet" 
>> 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 
>> 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" 
 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
 
 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/