-
Notifications
You must be signed in to change notification settings - Fork 263
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.
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
Needed: New maintainership of node-pre-gyp #657
Comments
Following up here that I did not receive any comments or questions of interest. Also |
If there is interest from corporate users of the package for more active maintenance and/or tacking some of the more prominent open issues, I may be able to put time/work on this starting spring. Feel free to reach out if relevant. |
Can this unmaintained status be announced in the README.md? That may help to find new maintainers and quickly understand that the recent issues can not be resolved meanwhile. |
…stall` fixes #1641 fixes #1721 fixes #1714 fixes #1713 fixes #1700 fixes #1704 - `@mapbox/node-pre-gyp` is effectively unmaintained [1] as has a few bugs which our users keep running into - it seems the prebuilt binary world has moved in favor of prebuild + it's various other forms - one option would be to use prebuildify to bundle all binaries into the package, but that's a step too far removed from the current situation for now - instead, we can use prebuild-install to download the binaries, and `prebuild` to build + upload the binaries - this means we can remove node-pre-gyp and fix a bunch of issues! [1]: mapbox/node-pre-gyp#657
…stall` fixes #1641 fixes #1721 fixes #1714 fixes #1713 fixes #1700 fixes #1704 - `@mapbox/node-pre-gyp` is effectively unmaintained [1] as has a few bugs which our users keep running into - it seems the prebuilt binary world has moved in favor of prebuild + it's various other forms - one option would be to use prebuildify to bundle all binaries into the package, but that's a step too far removed from the current situation for now - instead, we can use prebuild-install to download the binaries, and `prebuild` to build + upload the binaries - this means we can remove node-pre-gyp and fix a bunch of issues! - eventually, we could start providing electron prebuilt binaries too [1]: mapbox/node-pre-gyp#657
…stall` fixes #1641 fixes #1721 fixes #1714 fixes #1713 fixes #1700 fixes #1704 - `@mapbox/node-pre-gyp` is effectively unmaintained [1] as has a few bugs which our users keep running into - it seems the prebuilt binary world has moved in favor of prebuild + it's various other forms - one option would be to use prebuildify to bundle all binaries into the package, but that's a step too far removed from the current situation for now - instead, we can use prebuild-install to download the binaries, and `prebuild` to build + upload the binaries - this means we can remove node-pre-gyp and fix a bunch of issues! - eventually, we could start providing electron prebuilt binaries too [1]: mapbox/node-pre-gyp#657
Is there anyone who still has maintenance access to this repo?I am an active maintainer of
@petersirota, @yhahn, @willwhite, @mapsam https://github.com/nodejs/node-gyp/issues?q=is%3Aissue+label%3A%22node-pre-gyp+is+unmaintained%22 |
As well as being a |
It's funny waking up to a flurry of activity from a comment made more than a year ago... anyway... I wrote the pull requests mentioned by @springmeyer in the original post (which apparently have rotted a little in the past two years) while on @solarwinds paycheque and using two weeks of their time. I'm (thankfully) not employed there anymore, and while I am way busier than I was when I made the offer @cclauss refers to, if there is a funding, I'd consider. |
@springmeyer Seems like this can be solved by forking the repo, however the real issue is npm publish permission. While you might not have access to publish Perhaps you could grant npm publish permission for |
Hi folks, @mapsam here from Mapbox, thanks for engaging here and we really appreciate the eagerness to help maintain node-pre-gyp! The project has sorely missed regular updates from us at Mapbox as the teams' priorities have shifted. I'm putting together a plan to help grant the proper access to those who are interested in maintenance and will respond back when I have more details. We're considering all options right now, from granting NPM access and GitHub access, or even transferring the repository entirely to a new maintainer. If you'd like to reach out to me directly with any ideas feel free to ping me here in this ticket or email me at |
Hey folks, thanks for checking back in. I'd like to get moving on a plan so @cclauss and others can make necessary changes without waiting for a larger plan to go into effect. Very much appreciate the input and response so far! Here's what I'm planning: Phase 1 - "just get moving again"
Phase 2 - "future home"
Open to feedback here. Cheers! |
Thanks massively @mapsamI have merged a handful of pull requests that:
The AppVeyor tests fail so now I think we should only merge PRs that:
I am happy to review and merge those pull requests but I would kindly ask that they be as simple to review as possible. If I create my own pull requests (to add GitHub Actions) who can approve them (I cannot approve my own PRs)? |
If you have a branch with the GitHub Actions setup, I could send it as a PR so you can approve and merge it as a workaround for you not being able to approve and merge your own PRs. (I'm assuming you have only write access to this repo and there are permission restrictions you're facing if I understood your comment correctly) |
Yes. Permissions issue. All pull requests must be approved by a repo maintainer before they can be merged. I can approve and merge your PRs but I cannot approve my own PRs. |
@mapsam a minor suggestion to pass along since I cannot file issues against |
Thanks @cclauss! I looked at the branch protection settings for I'll be here for reviews for the moment but will be good to get another maintainer to help you out in the meantime. Happy to include @benmccann if that's helpful, but don't want to put pressure on anyone without their consent and explicit interest! We could always work on feature branches before merging into |
@benmccann I'll get a PR and release out for |
@benmccann @cclauss |
I'm happy to act as a maintainer in the short-term to get a release out. I'm probably not the best maintainer in the long-term as I don't directly use this package. It just happens to be in our dependency tree and so I'm trying to fix some deprecation warnings (mostly by removing packages when possible so that we don't risk the warnings re-occuring), but I'm not very familiar with the package and would be less able to review actual code changes Thanks for the new release of the eslint config Sam! I sent a PR here to use it |
I'd be interested in becoming a long-term maintainer for @benmccann @cclauss @mapsam I am making my way through the recent issues and PRs in this repo to gather context. If there are any specifics that would be helpful for me to focus on initially please tag me on them and I will take a look. |
@lukekarrys lovely, thank you for offering your time and expertise! I've sent you an invitation to be a maintainer of the repo. |
@lukekarrys Welcome to the pre-gyp maintainers team. First priority is to use the new GitHub Action for releasing to create a pre-release on NPM. That should not be the default release but should allow those who want to ask for it by version number to download it and try it out. After a week or two of listening to that feedback, please repeat the process to make a real production release. It would be best to do this BEFORE merging other changes because we have done a ton of Dependabot changes without any real world feedback. Small moves…. AFTER the real release is out we need to placate Dependabot and then create another production release. My expertise is Python, not JS so I am ecstatic to have your steadier hands on the wheel. Thanks! |
Thank you @lukekarrys both for volunteering and for all the reviews you've already given. 1.1.0-dev.1 was manually released on July 3. There has been just two small PRs with user visible changes committed since that time. There was one PR to replace I agree setting up the release process is fairly high priority. I think we could make some other changes in parallel since there's already a pre-release version out on npm available for testing containing the majority of prior changes. The other PRs I think are highest priority are replacing npmlog, which would address multiple deprecation warnings being caused by the project's transitive dependencies, and updating dependabot to silence noise in the PR queue. Unfortunately I only have experience with rennovate, so don't have a ton of experience with dependabot. I just returned from vacation last night, so can try to test out the dependabot config changes in my fork this week if you'd prefer to avoid the churn of experimenting with it a bit here. I also have PRs out to upgrade or remove the other direct dependencies that are behind. |
Was there any feedback on 1.1.0-dev.1? |
No complaints so far. I think it'd be nice to merge another batch of PRs and do another pre-release. |
Let’s let @lukekarrys decide. |
I'm stepping down from maintaining
node-pre-gyp
. For the next month and a half (until the end of June) I can be available to a) facilitate moving maintainer-ship to someone else and b) be available to answer any questions on the transition from that new maintainer or the wider community (on this ticket).However I will no longer be reviewing PRs, making releases, or responding to bug reports.
As far as a new maintainer, that maintainer could be:
In my mind, all are good options and I will consider any proposals and try to decide promptly (by the end of June) to find a good solution that ensures a)
node-pre-gyp
is well maintained going forward for the benefit of the entire node.js community and b) also satisfies Mapbox needs.So, please comment on this ticket if you or your org are interested. Or reach out to me to discuss by emailing me at dane@mapbox.com.
Thanks!
For those curious for extra context and history, here is a quick summary.
Since 2013 I (@springmeyer) have been the primary maintainer of
node-pre-gyp
. Over this time I've tended to be the single point of contact both for internal Mapbox customers of node-pre-gyp as well as for the wider node.js community (fielding requests from companies using node-pre-gyp for mission critical modules as well as tending to the public github issue queue).I've recruited help from various Mapbox colleagues over the years (thank you especially @mapsam, and @wilhelmberg) and from countless generous open source contributors (like @Mithgol, @murgatroid99, @brianreavis, @jschlight, and @bmacnaughton). I'm especially grateful to these external folks for helping to keep things chugging during times when I've been in management roles without any time for coding.
Recently I've been away on parental leave and coming back I can see how important it is to find a new maintainer for this module.
The main reasons are:
node-pre-gyp
maintenance at the level the node.js community needs (for example, look at all the great work from https://github.com/mapbox/node-pre-gyp/pulls/ronilan that needs attention)The quick timeline of node-pre-gyp is that:
node-sqlite3
,node-srs
,node-zipfile
, etc)apt
,rpm
,homebrew
, etc) to handle binary deploymentnode-mapnik
andnode-gdal
) included binaries over 1-200 MB in size (per platform) we knew that a system that stored the binaries inside the package published to https://npmjs.com/ would not scale well (instead it would be more scalable to have a system to store the binaries separately, per platform)npm install
(this becamenode-pre-gyp
).node-pre-gyp
publicly such that the internal tool that helped us scale our AWS cloud deployments could also be used to handle binary deployment for windows users of node-sqlite3node-pre-gyp
would become nothing more than the "art of the possible" and would inspire the Node.js community to find a solution inside of node core that would avoid anyone needingnode-pre-gyp
.node-pre-gyp
and over time also additional projects like https://github.com/prebuild/prebuild.node-pre-gyp
. But two things caused friction: a) prebuildify tooling works by storing the binaries inside the npm package which works for most use-cases but not for the Mapbox use-cases that involve really large binaries for many different platforms (https://github.com/prebuild/prebuild-install#note) and b) by the time prebuildify was created I was working on totally different things at Mapbox than node.js c++ addon development so I never found time to address a) with any creative solutions.node-pre-gyp
only supports storing binaries on s3 (which was all Mapbox needed in ~2013) and does not support a) private modules, b) posting to github releases (like the third-party https://github.com/bchr02/node-pre-gyp-github allows), or c) allowing binaries inside of the npm package. All of these things seem quite reasonable to support to me, but are not something I will be able to help with. Hence this issue. Thanks for reading all the way to here :)/cc @flippmoke @aswamina @danpat @yhahn @mapbox/security-and-compliance
The text was updated successfully, but these errors were encountered: