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.

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

Improve relations with nodejs packagers #245

Closed
jbergstroem opened this issue Nov 9, 2015 · 13 comments
Closed

Improve relations with nodejs packagers #245

jbergstroem opened this issue Nov 9, 2015 · 13 comments

Comments

@jbergstroem
Copy link
Member

This has been on my todo for a good while -- lets make it more visible so others can annoy me to get it done. My intention is to email all packagers of nodejs, ranging from various linux distributions to freebsd, smartos or whatnot. A healthy relationship between us and downstream will improve latency and quality of releases as well as most likely getting bug reports and patches in return.

Here's a draft email I've been writing that's to be sent out to a list of people. Not sure if I should list all these maintainers here -- if others think so, I'm happy to collectively build on that list.

Sendout

Hi,
I'm part of the nodejs build group (https://github.com/nodejs/build, https://gitter.im/nodejs/build, #node-build@freenode). The reason I'm emailing you is because you seem to be part of maintaining and packaging nodejs. My ambition is to better understand what problems (if any) you might be facing packaging node but also flat that our build group will be generally available for questions and feedback on how we can make node better for your package manager. The end goal is to make sure the user experience is as good as possible through all channels of distribution.

We have a document that outlines different ways of installing nodejs (https://nodejs.org/en/download/package-manager/). Are these instructions up to date or are you perhaps missing from the list?

I'm also happy to help out should you have floating patches you want us to help landing (both nodejs and v8 or other projects we depend on).

Would you also be interested in being part of a mailing list where we'd send out an email on $version_bump outlining possible actions from a build point of view? Dependencies, toolchain, abi breakages, etc. It could look like this:

Nodejs 4.2.0 is out

  • We've updated deps/icu from 55 to 56 meaning should you build against a shared library you're suggested to follow the dependency bump.
  • NPM now ships with a new command; "self_destruct". This will be auto-installed should you call make install, but if you manually install this needs to follow suit.

Lets keep this short but it'd be great to hear from you - even if its just to say you got my email. You can reach me at bugs@bergstroem.nu or jbergstroem@freenode.

Thanks,
Johan Bergström
nodejs build group

@PeterDaveHello
Copy link
Member

👍

@mhdawson
Copy link
Member

+1 from me and there are a few people I'd want to add to the list from IBM.

@mikeal
Copy link
Contributor

mikeal commented Nov 10, 2015

What does the hand-off look like right now between the Build/Release team and our Docker WG? @nodejs/docker

@chorrell
Copy link

+1

There are some Joyent people who package Node.js for pkgsrc that should be included. Also, SmartOS/pkgsrc is absent from here: https://nodejs.org/en/download/package-manager/

@jbergstroem
Copy link
Member Author

@mikeal we have overlap in terms of people. The trust to push to the docker repo lies in the docker group.

@Starefossen
Copy link
Member

@mikeal as Johan said there is a strong overlap between the two working groups. However we do want to automate the process of getting new versions of the Docker Images as much as possible. There is also a desire of getting new Docker Images tested - preferably through the existing Jenkins CI setup.

@Starefossen
Copy link
Member

@chvostek
Copy link

@jbergstroem , awesome that you are spearheading this effort. As a FreeBSD sysadmin and port maintainer, I can tell you that the mere fact that you're interested in improving this process means a heck of a lot.

As I mentioned on the other issue thread where this came up, the FreeBSD community recommends strongly against the use of externally-derived binary packages. In FreeBSD, binary packages are always built from "ports", and the delay in getting up-to-date packages is almost always in getting the port updated, rather than building packages from the updated port.

As I also mentioned, Node developers have done a GREAT job so far of writing code that compiles cleanly in FreeBSD. At this point, the www/node FreeBSD port requires no patches to build or install, and it has almost no dependencies. This is rare and wonderful. :)

Regarding your $version_bump mailing list suggestion, I imagine many people would be interested in joining that list beyond just package managers. I know I would, so that if a port update becomes available, I have an easier-to-read description of the changes upgrading will require on my systems. On a related note, many people use tools like portscout to be notified when the ports they maintain need to be updated.

How might we update the actual FreeBSD port when a version gets bumped, though?

As a first step, could we automate the process of producing a patch on the port's Makefile, and submit that through the normal update channels? If dependencies and the package list aren't changing, the update could be as little as two lines in two files (the PORTVERSION in the Makefile and the sha256 in the distinfo).

@jbergstroem
Copy link
Member Author

@chvostek without turning this issue into the actual email, here's a few comments. In the coming weeks I reckon the maintainers can expect a similar email from me.

  • Coming from ~15 years of using different distros/os:es I understand that even if upstream wants tight control we can't assume that distributions should leave packaging to us. Upstream rarely sees the full picture.
  • All package managers have different ways of handling security (most common scenario for nodejs is building against a shared openssl). Our ambition should be to make it as easy as possible for managers to enforce their own routines.
  • We already have a few options in place to notify people about version bumps. If I garner enough interest (and time), the "package manager mailing list" would give you enough information about what you need to care about from a packaging point of view -- not so much about new features, bug fixes or improvements. There are distributions that strives to build against an environment that has as many shared dependencies as possible. We've released enough versions to create a legacy and need to support that.

@chvostek
Copy link

@jbergstroem ... Every OS community has its conventions. I haven't been involved in package building on Linux in the last few years, but I am very involved with FreeBSD and happy to help find common ground in that OS.

Our ambition should be to make it as easy as possible for managers to enforce their own routines.

Yes, that's exactly what I was suggesting, both in the other issue and here, above.

I have some ideas as to how this process might be semi-automated for FreeBSD. As a long time FreeBSD port maintainer, I can tell you that anything that reduces my workload is looked upon favourably. I also have feedback on the "sendout" sample you included when you opened this issue.

If your preference is to deal only with the individuals who are package maintainers for node, and you feel as if you'll have success following that route, then I'll withdraw from this issue and wish you the best of luck.

@jbergstroem
Copy link
Member Author

@chvostek for freebsd-specific improvements I think that discussion better lives somewhere else (we're still interested in having it). Perhaps ping me on irc or by email? (jbergstroem@freenode, #node-build or bugs at bergstroem dot nu).

As for improvements to the email, shoot! I will attempt to get the email out sometime next week.

@Trott
Copy link
Member

Trott commented Mar 30, 2018

@nodejs/build @jbergstroem Should this remain open? Is it something that we might consider asking another group to help with or take on, such as @nodejs/user-feedback or @nodejs/community-committee?

@Trott
Copy link
Member

Trott commented Apr 25, 2019

Given that the last time there was meaningful activity in this issue was over 3 years ago, I'm going to close it. Feel free to re-open if you think that's the right thing, although consider opening one or more very (narrow/specific) new issue(s) instead.

@Trott Trott closed this as completed Apr 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants