Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

governance: Add new Collaborators #234

Closed
rvagg opened this issue Jan 3, 2015 · 52 comments
Closed

governance: Add new Collaborators #234

rvagg opened this issue Jan 3, 2015 · 52 comments

Comments

@rvagg
Copy link
Member

rvagg commented Jan 3, 2015

I was going to do this as a comment in #230 but it got out of hand so it's probably best as a separate issue.

As mentioned in #233, we need to be more rigorous about adding collaborators to the project. So far there's just the TC + @cjihrig + @mikeal + @rvagg in the core team(s) (plus some additionals that were invited for historical reasons but haven't participated yet) and then there's other teams like Website and Build that have additional people.

After reviewing the closed io.js pull requests (node-forward/node is gone so I don't know if there was anything useful in there re PRs), I've come up with a very subjective list. I've eliminated PRs that were not merged and some trivial ones, mainly additions to documentation that I wouldn't count as "significant".

To get the ball rolling, I've come up with a significance rating, a number from 1 to 5, and assigned it to each of the PRs below. These are my subjective ratings and relate to the impact of the PR in terms of amount of code and also significance of the change. This is a very tricky thing to do and I'm sure others would come up with different numbers. The only 1's I've included here are ones where the contributor has made multiple PRs, to take into account their compound contribution.

It's up to the TC to approve the addition of people so at this next meeting I'd like to put this on the agenda:

  1. Using the above data and looking at the kinds of modifications being considered, can the TC come up with a minimum bar for addition to the Collaborators group (I suspect this to be somewhat subjective but that's OK as long as there can be some consistency across each meeting where new additions are being considered).
  2. Given some kind of resolution of the above, which of the above individuals can be added to the Collaborators group?

So I'd ask TC members to have a browse through this list and have a think about how you would approach this. My personal opinion is the more the merrier in most cases so there should be a liberal attitude towards adding people, just not for trivial changes.

Additionally, we'll need approval from each of the above individuals that they actually want to be added, you can do that here with a simple comment if you like or someone can chase you up afterwards.
@rvagg rvagg added the tc-agenda label Jan 3, 2015
@rvagg
Copy link
Member Author

rvagg commented Jan 3, 2015

For those on the list, here's the Collaborator Guide I'm proposing be pulled in so you can get an idea of what this is all about: https://github.com/rvagg/io.js/blob/contributing/COLLABORATOR_GUIDE.md plus the Governance structure: https://github.com/rvagg/io.js/blob/contributing/GOVERNANCE.md

@mikeal
Copy link
Contributor

mikeal commented Jan 3, 2015

+1

Additionally, we'll need approval from each of the above individuals that they actually want to be added

With the way GitHub orgs work now we should just be able to add them and they can choose to accept the org membership or not, it doesn't force it on them like it used to.

@a0viedo
Copy link
Member

a0viedo commented Jan 6, 2015

Just out of curiosity, where I can find the code style guidelines?

@bnoordhuis
Copy link
Member

@a0viedo They are mostly the Google style guides for C++ and JS with some minor extensions. make cpplint jslint will tell you if your code conforms. (Note that files in test/ are not checked.)

@mikeal
Copy link
Contributor

mikeal commented Jan 6, 2015

Is there a place anywhere in our contributing guide that references the Google style guides?

@a0viedo
Copy link
Member

a0viedo commented Jan 6, 2015

@mikeal I think I read that on joyent/node guidelines but not in iojs. Also, is there any specific reason for not including a .jshintrc file?

@chrisdickinson
Copy link
Contributor

@a0viedo the project is currently configured to use the closure linter (via make jslint). I'm not super opposed to moving to {e,j}s{h,l}int in the future, so long as it doesn't come with a giant style change patch. The one issue I can see is that we get into sort of "bootstrap-y" issues, where to lint the project you have to have a working copy of node around, and most of the tooling around the project explicitly avoids that at present.

@bnoordhuis
Copy link
Member

Apropos the list of collaborators: LGTM. We could argue all day about what constitutes a meaningful contribution but I agree with @rvagg, it's better to be liberal. Maybe we can add some kind of inactivity counter (e.g. 3 months and you're off the list again) to give people an incentive to keep contributing.

@rvagg rvagg mentioned this issue Jan 7, 2015
Closed
@chrisdickinson
Copy link
Contributor

To expand on my comment from the TC meeting: I am strongly in favor of getting to a point where we can rapidly add many new collaborators at once. Part of that, though, is making sure that we're spinning up new collaborators effectively: making sure that they understand the culture of the project, and feel comfortable with the extents of their new responsibilities.

I bring this up because it was actually a bit of an impediment to me when I first got the commit bit on joyent/node: it was hard to get to a point where I felt comfortable closing an issue (especially issues that core team members had commented on), because I didn't have a good sense of what the expectations were for my new role. Eventually I got over it and started closing issues / commenting / taking more ownership, but I distinctly remember thinking to myself beforehand: "Well, I suppose I'll find out if I'm not supposed to be doing this when they take away my commit bit!" I'd like to avoid that step for new collaborators, if possible.

A good way to do that might be to have an existing collaborator volunteer to shepherd a new collaborator into the project -- for a week or two, be the point of contact for any question the new collaborator might have, and keep an eye on what they're doing in the repo to make sure they're comfortable making changes, reviewing, commenting, closing issues, etc.

Note that this is less about "protecting the project" than it is about making sure that we're creating an environment that actively encourages people to take ownership of the project. I'd be happy to take this on for 1-2 folks, if we decide to go this route. As we get an idea of how much time this takes, we can start increasing the number of folks we shepherd in at a time; or, as the pool of collaborators expands, we can rely on them shouldering some of that effort.

@lxe
Copy link

lxe commented Jan 7, 2015

Don't make me a collaborator just yet. Let me take a deep dive into this, and get really familiar/comfortable with project goals, priorities and conventions. I won't be comfortable with closing issues and making feature decisions at this point.

@rvagg rvagg mentioned this issue Jan 12, 2015
Closed
@mathiasbynens
Copy link
Contributor

FWIW, I completely agree with what was said during the TC meeting. I wouldn’t mind being added as a collaborator if only for the Punycode-related stuff (and possibly documentation) but don’t expect me to do any work on the C++ parts of io.js.

@rvagg
Copy link
Member Author

rvagg commented Jan 18, 2015

@bnoordhuis has nominated @Fishrock123 and @Qard for being helpful in support and issue responsiveness, we should also discuss how non-code contributions feed into the decision to add people.

@cjihrig
Copy link
Contributor

cjihrig commented Jan 19, 2015

+1 for adding them. If someone were to be brought on in a "docs only" fashion, we could just give them a commit bit and immediately revert anything else that were committed.

@rvagg
Copy link
Member Author

rvagg commented Jan 19, 2015

One of my dreams for "OPEN Open Source" is to have a github bot that could outlaw pushes to master (especially including force pushes) without pull request by immediately reverting them.

That would be ideal here and we wouldn't even need to care about the reasons we give someone commit access the visibility on changes goes right up.

Just putting that out there in case someone gets inspired by the idea because I've never had the time to actually implement this.

@rvagg rvagg mentioned this issue Jan 19, 2015
Closed
@jbergstroem
Copy link
Member

I think one aspect that hasn't been expanded on just yet (@chrisdickinson brought it up) is how important tooling is to make you feel "comfortable" committing, reviewing or working with a project in general. The more tools io.js can provide in terms of telling collaborators they're making the correct decision (be it linters, test suites, spell checkers, commit text reviewers or whatnot), the friendlier the environment will feel.

It's pretty common among os distributions/package managers to have tools that for instance ensures that the package you are modifying will work with the packages that depends on it; or if the requirements that package have (be it tooling for building or installing into correct paths) looks good. If those weren't in place, the process would be considerably slower and would still be open to human error.

A pretty common option here among open source projects is introducing bots that aids with this. I think a level up from that would be providing the same input through these tools so a person can make choices based on them -- for instance, administrating open issues.

@rvagg
Copy link
Member Author

rvagg commented Jan 19, 2015

Something I want to note while I think of it: perhaps we should schedule an onboarding hangout with new collaborators when they are added to talk through any concerns they have and reinforce the important parts of being a collaborator: git stuff, how to handle issues, how to take responsibility, etc. The hangout could be hosted by a couple of existing collaborators, @chrisdickinson comes to mind as someone good for this. I'd like to see a path that new collaborators feel enough ownership to start hacking in to the issues and pull requests to trim the list and take action where the action is straightforward.

@piscisaureus
Copy link
Contributor

We should just give out commit bits on an as-needed basis.

Instead of handing out commit bits, I think it's much more desirable to give influence to contributors, in the form of a vote.

@chrisdickinson
Copy link
Contributor

@rvagg I would be happy to help with something like this for new collaborators – this is pretty much precisely what I want. I can put together a rough outline of what I'd like to go over for new folk at an onboarding like this.

@Qard
Copy link
Member

Qard commented Jan 19, 2015

You could turn off issues for iojs/io.js and redirect to iojs/bugs, iojs/feature-requests, etc. Then you don't need to care so much about commit access to the repo.

@formula1
Copy link

You could also break the project up into sub modules then make io.js the
culmination of those sub modules. This would make giving permission a lot
easier per component

On Monday, January 19, 2015, Stephen Belanger notifications@github.com
wrote:

You could turn off issues for iojs/io.js and redirect to iojs/bugs,
iojs/feature-requests, etc. Then you don't need to care so much about
commit access to the repo.

—
Reply to this email directly or view it on GitHub
#234 (comment).

Samuel G. Tobia
(609) 751-1341
Samtobia@gmail.com

@smikes
Copy link
Contributor

smikes commented Jan 19, 2015

You could turn off issues for iojs/io.js and redirect to iojs/bugs, iojs/feature-requests, etc. Then you don't need to care so much about commit access to the repo.

Absolutely; this is important. I would suggest even going so far as to turn off issues for iojs/io.js and only allow pull requests.

@mikeal
Copy link
Contributor

mikeal commented Jan 19, 2015

I'm -1 on turning Issues off. People that are new to the project instinctively look for Issues here. Giving people commit bits in order to help with Issues is not dangerous. This is git, even if they are blatantly malicious we can easily recover.

@smikes
Copy link
Contributor

smikes commented Jan 19, 2015

It's not the blatantly malicious I'd worry about: it's two things -- the well-intentioned but misguided; and the transition back to a single combined node/iojs repository.

A different approach: put in place a policy of pruning committers (you can always get the bit back again, right?)

@mikeal
Copy link
Contributor

mikeal commented Jan 19, 2015

pruning

That's an interesting idea. My experience with the levelup project is that several contributors are still active in Issues and give great feeback but are no longer actively contributing code of their own. But, as long as the pruning logic considered activity in Issues and PRs I think it would be fine.

@Fishrock123
Copy link
Contributor

raises hand for issues help

@Mickael-van-der-Beek
Copy link

I'd be interested although I've not yet committed any code to IO.js yet, I did for Node.js.

@rvagg rvagg mentioned this issue Jan 22, 2015
Closed
@shigeki
Copy link
Contributor

shigeki commented Jan 22, 2015

@bnoordhuis Thanks for the nomination for the Collaborators. I'm very glad to work in io.js.
@chrisdickinson I can join the hangout in the next week or later.

@rvagg
Copy link
Member Author

rvagg commented Jan 22, 2015

@shigeki please respond via https://doodle.com/ehq3u887fdvd4sss

@shigeki
Copy link
Contributor

shigeki commented Jan 22, 2015

@rvagg Thanks. I missed "Cannot make it" button.

@chrisdickinson
Copy link
Contributor

@shigeki Cool – assuming all goes well, there should be another fairly shortly afterwards for those who can't make Friday.

@chrisdickinson
Copy link
Contributor

OK! Tomorrow I'll run two groups, one at 11AM PST and one at 1PM PST.

For the 11AM group:

For the 1PM group:

I'll plan on having 15-20 minutes of content. If you could send questions to chris at neversaw dot us beforehand, I'd be happy to answer them (and we'll have time to cover other questions as well). After this batch is done, I'll collect feedback and I'll start a doodle for next week.

Thanks very much, everyone!

@bk2204
Copy link
Contributor

bk2204 commented Jan 22, 2015

I appreciate the offer, but I think for the moment I'd rather send more patches before becoming an official contributor to the project. I'm glad y'all found the contributions useful, though.

@tellnes
Copy link
Contributor

tellnes commented Jan 22, 2015

I'm interested also, but it will not be regular. It will be now and then when I have some extra time.

English is not my first language so I'm more a reader than a writer when it come to discussions, but I will probably contributes to some issues. From time to time I probably can contribute some code also.

I'm watching the repo, but when the backlog is getting to big, I'll click the read all button. It is better to see some of the issues than none.

Also, I can't make it to any of the times tomorrow. But since @chrisdickinson already have set the groups, I'm probably not getting in in this batch anyway.

@Qard
Copy link
Member

Qard commented Jan 22, 2015

@chrisdickinson Cool. Looking forward to it! :)

@rvagg rvagg mentioned this issue Jan 23, 2015
Closed
@mikeal
Copy link
Contributor

mikeal commented Jan 23, 2015

@chrisdickinson these will be on hangouts on air right? do you need to be added to the youtube channel?

@chrisdickinson
Copy link
Contributor

@mikeal These are not hangouts on air, just currently doing ad-hoc hangouts. I thought about doing them on-air, but wanted to lean towards privacy to encourage question-asking. I'm open to other opinions on that, though!

Re: the youtube channel, I don't think I'm added, but I could be wrong. Will check after this upcoming onboarding.

@sam-github
Copy link
Contributor

@rvagg I'm interested, but missed the first doodle in my flood of iojs email. Will there be another onboarding?

@rvagg
Copy link
Member Author

rvagg commented Jan 26, 2015

@sam-github absolutely, I think @chrisdickinson will be scheduling another onboarding this week or maybe early next week. There will likely be some discussion about the process at the next TC to refine it but we certainly just want to make the path to adding extra collaborators smooth.

@chrisdickinson
Copy link
Contributor

OK! Sorry this took me so long, but the doodle for the 2nd round of onboarding is up!

If you've been recommended by @iojs/tc, please respond. If you missed the first time and can't make it this time either, let me know and I can figure out another time for you. Thanks all!

@robertkowalski
Copy link
Contributor

can't make it this time, as i am organizing http://day.couchdb.org/ - we
are preparing friday evening and the conf is on saturday!

On Fri, Jan 30, 2015 at 10:55 PM, Chris Dickinson notifications@github.com
wrote:

OK! Sorry this took me so long, but the doodle for the 2nd round of
onboarding is up https://doodle.com/geyp2bfzru2vyvt4!

If you've been recommended by @iojs/tc
https://github.com/orgs/iojs/teams/tc, please respond. If you missed
the first time and can't make it this time either, let me know and I
can figure out another time for you. Thanks all!

—
Reply to this email directly or view it on GitHub
#234 (comment).

@rvagg rvagg mentioned this issue Jan 31, 2015
Closed
@rvagg
Copy link
Member Author

rvagg commented Jan 31, 2015

overflowed to #680

@rvagg rvagg closed this as completed Jan 31, 2015
@rvagg rvagg removed the tc-agenda label Feb 3, 2015
@chrisdickinson chrisdickinson mentioned this issue Feb 20, 2015
Closed
@chrisdickinson chrisdickinson mentioned this issue Mar 4, 2015
Closed
@Fishrock123 Fishrock123 mentioned this issue Apr 28, 2015
Closed
@Fishrock123 Fishrock123 mentioned this issue Jul 3, 2015
Closed
@rvagg rvagg mentioned this issue Aug 17, 2015
Closed
@jasnell jasnell mentioned this issue Oct 21, 2015
Closed
Trott pushed a commit to npm/node that referenced this issue Aug 20, 2019
@isaacs @Trott
deps: update npm to 6.11.0
5fb908e 
Full release notes:

A few meaty bugfixes, and introducing `peerDependenciesMeta`.

FEATURES

* [`a12341088`](npm/cli@a123410)
  [nodejs#224](npm/cli#224) Implements
  peerDependenciesMeta ([@arcanis](https://github.com/arcanis))
* [`2f3b79bba`](npm/cli@2f3b79b)
  [nodejs#234](npm/cli#234) add new forbidden 403
  error code ([@claudiahdz](https://github.com/claudiahdz))

BUGFIXES

* [`24acc9fc8`](npm/cli@24acc9f)
  and
  [`45772af0d`](npm/cli@45772af)
  [nodejs#217](npm/cli#217)
  [npm.community#8863](https://npm.community/t/installing-the-same-module-under-multiple-relative-paths-fails-on-linux/8863)
  [npm.community#9327](https://npm.community/t/reinstall-breaks-after-npm-update-to-6-10-2/9327,)
  do not descend into directory deps' child modules, fix shrinkwrap
  files that inappropriately list child nodes of symlink packages
  ([@isaacs](https://github.com/isaacs) and
  [@salomvary](https://github.com/salomvary))
* [`50cfe113d`](npm/cli@50cfe11)
  [nodejs#229](npm/cli#229) fixed typo in semver doc
  ([@gall0ws](https://github.com/gall0ws))
* [`e8fb2a1bd`](npm/cli@e8fb2a1)
  [nodejs#231](npm/cli#231) Fix spelling mistakes in
  CHANGELOG-3.md ([@XhmikosR](https://github.com/XhmikosR))
* [`769d2e057`](npm/cli@769d2e0)
  [npm/uid-number#7](npm/uid-number#7) Better
  error on invalid `--user`/`--group` configs. This addresses the issue
  when people fail to install binary packages on Docker and other
  environments where there is no 'nobody' user.
  ([@isaacs](https://github.com/isaacs))
* [`8b43c9624`](npm/cli@8b43c96)
  [nodejs#28987](nodejs#28987)
  [npm.community#6032](https://npm.community/t/npm-ci-doesnt-respect-npmrc-variables/6032)
  [npm.community#6658](https://npm.community/t/npm-ci-doesnt-fill-anymore-the-process-env-npm-config-cache-variable-on-post-install-scripts/6658)
  [npm.community#6069](https://npm.community/t/npm-ci-does-not-compile-native-dependencies-according-to-npmrc-configuration/6069)
  [npm.community#9323](https://npm.community/t/npm-6-9-x-not-passing-environment-to-node-gyp-regression-from-6-4-x/9323/2)
  Fix the regression where random config values in a .npmrc file are not
  passed to lifecycle scripts, breaking build processes which rely on
  them.  ([@isaacs](https://github.com/isaacs))
* [`8b85eaa47`](npm/cli@8b85eaa)
  save files with inferred ownership rather than relying on `SUDO_UID`
  and `SUDO_GID`. ([@isaacs](https://github.com/isaacs))
* [`b7f6e5f02`](npm/cli@b7f6e5f)
  Infer ownership of shrinkwrap files
  ([@isaacs](https://github.com/isaacs))
* [`54b095d77`](npm/cli@54b095d)
  [nodejs#235](npm/cli#235) Add spec to dist-tag
  remove function ([@theberbie](https://github.com/theberbie))

DEPENDENCIES

* [`dc8f9e52f`](npm/cli@dc8f9e5)
  `pacote@9.5.7`: Infer the ownership of all unpacked files in
  `node_modules`, so that we never have user-owned files in root-owned
  folders, or root-owned files in user-owned folders.
  ([@isaacs](https://github.com/isaacs))
* [`bb33940c3`](npm/cli@bb33940)
  `cmd-shim@3.0.0`:
  * [`9c93ac3`](npm/cmd-shim@9c93ac3)
    [#2](npm/cmd-shim#2)
    [npm#3380](npm/npm#3380) Handle
    environment variables properly
    ([@basbossink](https://github.com/basbossink))
  * [`2d277f8`](npm/cmd-shim@2d277f8)
    [nodejs#25](npm/cmd-shim#25)
    [nodejs#36](npm/cmd-shim#36)
    [nodejs#35](npm/cmd-shim#35) Fix 'no shebang' case
    by always providing `$basedir` in shell script
    ([@igorklopov](https://github.com/igorklopov))
  * [`adaf20b`](npm/cmd-shim@adaf20b)
    [nodejs#26](npm/cmd-shim#26) Fix `$*` causing an
    error when arguments contain parentheses
    ([@satazor](https://github.com/satazor))
  * [`49f0c13`](npm/cmd-shim@49f0c13)
    [nodejs#30](npm/cmd-shim#30) Fix paths for
    MSYS/MINGW bash ([@dscho](https://github.com/dscho))
  * [`51a8af3`](npm/cmd-shim@51a8af3)
    [nodejs#34](npm/cmd-shim#34) Add proper support
    for PowerShell ([@ExE-Boss](https://github.com/ExE-Boss))
  * [`4c37e04`](npm/cmd-shim@4c37e04)
    [#10](npm/cmd-shim#10) Work around quoted
    batch file names ([@isaacs](https://github.com/isaacs))
* [`a4e279544`](npm/cli@a4e2795)
  `npm-lifecycle@3.1.3` ([@isaacs](https://github.com/isaacs)):
    * fail properly if `uid-number` raises an error
    * [`7086a1809`](npm/cli@7086a18)
  `libcipm@4.0.3` ([@isaacs](https://github.com/isaacs))
* [`8845141f9`](npm/cli@8845141)
  `read-package-json@2.1.0` ([@isaacs](https://github.com/isaacs))
* [`51c028215`](npm/cli@51c0282)
  `bin-links@1.1.3` ([@isaacs](https://github.com/isaacs))
* [`534a5548c`](npm/cli@534a554)
  `read-cmd-shim@1.0.3` ([@isaacs](https://github.com/isaacs))
* [`3038f2fd5`](npm/cli@3038f2f)
  `gentle-fs@2.2.1` ([@isaacs](https://github.com/isaacs))
* [`a609a1648`](npm/cli@a609a16)
  `graceful-fs@4.2.2` ([@isaacs](https://github.com/isaacs))
* [`f0346f754`](npm/cli@f0346f7)
  `cacache@12.0.3` ([@isaacs](https://github.com/isaacs))
* [`ca9c615c8`](npm/cli@ca9c615)
  `npm-pick-manifest@3.0.0` ([@isaacs](https://github.com/isaacs))
* [`b417affbf`](npm/cli@b417aff)
  `pacote@9.5.8` ([@isaacs](https://github.com/isaacs))

TESTS

* [`b6df0913c`](npm/cli@b6df091)
  [nodejs#228](npm/cli#228) Proper handing of
  /usr/bin/node lifecycle-path test
  ([@olivr70](https://github.com/olivr70))
* [`aaf98e88c`](npm/cli@aaf98e8)
  `npm-registry-mock@1.3.0` ([@isaacs](https://github.com/isaacs))
isaacs added a commit to npm/node that referenced this issue Aug 21, 2019
@isaacs
deps: update npm to 6.11.1
ee11376 
Full changelog:

6.11.1 (2019-08-20):

Fix a regression for windows command shim syntax.

* [`37db29647`](npm/cli@37db296)
  `cmd-shim@3.0.2` ([@isaacs](https://github.com/isaacs))

v6.11.0 (2019-08-20):

A few meaty bugfixes, and introducing `peerDependenciesMeta`.

FEATURES

* [`a12341088`](npm/cli@a123410)
  [nodejs#224](npm/cli#224) Implements
  peerDependenciesMeta ([@arcanis](https://github.com/arcanis))
* [`2f3b79bba`](npm/cli@2f3b79b)
  [nodejs#234](npm/cli#234) add new forbidden 403 error
  code ([@claudiahdz](https://github.com/claudiahdz))

BUGFIXES

* [`24acc9fc8`](npm/cli@24acc9f)
  and
  [`45772af0d`](npm/cli@45772af)
  [nodejs#217](npm/cli#217)
  [npm.community#8863](https://npm.community/t/installing-the-same-module-under-multiple-relative-paths-fails-on-linux/8863)
  [npm.community#9327](https://npm.community/t/reinstall-breaks-after-npm-update-to-6-10-2/9327,)
  do not descend into directory deps' child modules, fix shrinkwrap files
  that inappropriately list child nodes of symlink packages
  ([@isaacs](https://github.com/isaacs) and
  [@salomvary](https://github.com/salomvary))
* [`50cfe113d`](npm/cli@50cfe11)
  [nodejs#229](npm/cli#229) fixed typo in semver doc
  ([@gall0ws](https://github.com/gall0ws))
* [`e8fb2a1bd`](npm/cli@e8fb2a1)
  [nodejs#231](npm/cli#231) Fix spelling mistakes in
  CHANGELOG-3.md ([@XhmikosR](https://github.com/XhmikosR))
* [`769d2e057`](npm/cli@769d2e0)
  [npm/uid-number#7](npm/uid-number#7) Better
  error on invalid `--user`/`--group` configs. This addresses the issue
  when people fail to install binary packages on Docker and other
  environments where there is no 'nobody' user.
  ([@isaacs](https://github.com/isaacs))
* [`8b43c9624`](npm/cli@8b43c96)
  [nodejs#28987](nodejs#28987)
  [npm.community#6032](https://npm.community/t/npm-ci-doesnt-respect-npmrc-variables/6032)
  [npm.community#6658](https://npm.community/t/npm-ci-doesnt-fill-anymore-the-process-env-npm-config-cache-variable-on-post-install-scripts/6658)
  [npm.community#6069](https://npm.community/t/npm-ci-does-not-compile-native-dependencies-according-to-npmrc-configuration/6069)
  [npm.community#9323](https://npm.community/t/npm-6-9-x-not-passing-environment-to-node-gyp-regression-from-6-4-x/9323/2)
  Fix the regression where random config values in a .npmrc file are not
  passed to lifecycle scripts, breaking build processes which rely on them.
  ([@isaacs](https://github.com/isaacs))
* [`8b85eaa47`](npm/cli@8b85eaa)
  save files with inferred ownership rather than relying on `SUDO_UID` and
  `SUDO_GID`. ([@isaacs](https://github.com/isaacs))
* [`b7f6e5f02`](npm/cli@b7f6e5f)
  Infer ownership of shrinkwrap files
  ([@isaacs](https://github.com/isaacs))
* [`54b095d77`](npm/cli@54b095d)
  [nodejs#235](npm/cli#235) Add spec to dist-tag remove
  function ([@theberbie](https://github.com/theberbie))

DEPENDENCIES

* [`dc8f9e52f`](npm/cli@dc8f9e5)
  `pacote@9.5.7`: Infer the ownership of all unpacked files in
  `node_modules`, so that we never have user-owned files in root-owned
  folders, or root-owned files in user-owned folders.
  ([@isaacs](https://github.com/isaacs))
* [`bb33940c3`](npm/cli@bb33940)
  `cmd-shim@3.0.0`:
  * [`9c93ac3`](npm/cmd-shim@9c93ac3)
    [#2](npm/cmd-shim#2)
    [npm#3380](npm/npm#3380) Handle environment
    variables properly ([@basbossink](https://github.com/basbossink))
  * [`2d277f8`](npm/cmd-shim@2d277f8)
    [nodejs#25](npm/cmd-shim#25)
    [nodejs#36](npm/cmd-shim#36)
    [nodejs#35](npm/cmd-shim#35) Fix 'no shebang' case by
    always providing `$basedir` in shell script
    ([@igorklopov](https://github.com/igorklopov))
  * [`adaf20b`](npm/cmd-shim@adaf20b)
    [nodejs#26](npm/cmd-shim#26) Fix `$*` causing an
    error when arguments contain parentheses
    ([@satazor](https://github.com/satazor))
  * [`49f0c13`](npm/cmd-shim@49f0c13)
    [nodejs#30](npm/cmd-shim#30) Fix paths for MSYS/MINGW
    bash ([@dscho](https://github.com/dscho))
  * [`51a8af3`](npm/cmd-shim@51a8af3)
    [nodejs#34](npm/cmd-shim#34) Add proper support for
    PowerShell ([@ExE-Boss](https://github.com/ExE-Boss))
  * [`4c37e04`](npm/cmd-shim@4c37e04)
    [#10](npm/cmd-shim#10) Work around quoted
    batch file names ([@isaacs](https://github.com/isaacs))
* [`a4e279544`](npm/cli@a4e2795)
  `npm-lifecycle@3.1.3` ([@isaacs](https://github.com/isaacs)):
    * fail properly if `uid-number` raises an error
* [`7086a1809`](npm/cli@7086a18)
  `libcipm@4.0.3` ([@isaacs](https://github.com/isaacs))
* [`8845141f9`](npm/cli@8845141)
  `read-package-json@2.1.0` ([@isaacs](https://github.com/isaacs))
* [`51c028215`](npm/cli@51c0282)
  `bin-links@1.1.3` ([@isaacs](https://github.com/isaacs))
* [`534a5548c`](npm/cli@534a554)
  `read-cmd-shim@1.0.3` ([@isaacs](https://github.com/isaacs))
* [`3038f2fd5`](npm/cli@3038f2f)
  `gentle-fs@2.2.1` ([@isaacs](https://github.com/isaacs))
* [`a609a1648`](npm/cli@a609a16)
  `graceful-fs@4.2.2` ([@isaacs](https://github.com/isaacs))
* [`f0346f754`](npm/cli@f0346f7)
  `cacache@12.0.3` ([@isaacs](https://github.com/isaacs))
* [`ca9c615c8`](npm/cli@ca9c615)
  `npm-pick-manifest@3.0.0` ([@isaacs](https://github.com/isaacs))
* [`b417affbf`](npm/cli@b417aff)
  `pacote@9.5.8` ([@isaacs](https://github.com/isaacs))

TESTS

* [`b6df0913c`](npm/cli@b6df091)
  [nodejs#228](npm/cli#228) Proper handing of
  /usr/bin/node lifecycle-path test
  ([@olivr70](https://github.com/olivr70))
* [`aaf98e88c`](npm/cli@aaf98e8)
  `npm-registry-mock@1.3.0` ([@isaacs](https://github.com/isaacs))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests