Repository navigation
(CANCELLED) LTS WG Meeting - 2016-12-12 8:00 PM UTC #170
Description
Invited
@nodejs/lts
When
🎉 It didn't happen! 🎉
Where
NOWHERE
Agenda
nodejs/node
- crypto: allow adding extra certs to well-known CAs #9139
- Approval to land on v4 and v6
- Is this important enough to release v4.8 as the next
Argonrelease /cc @sam-github- Did you notice I found a good use for the code names there! 🎉
In closed environments, self-signed or privately signed certificates are
commonly used, and rejected by Node.js since their root CAs are not
well-known. Allow extending the set of well-known compiled-in CAs via
environment, so they can be set as a matter of policy.
- backport util.inspect.custom #9688
Add a util.inspect.Custom Symbol which can be used to customize util.inspect() output. Providing obj[util.inspect.Custom] works like providing obj.inspect, except that the former allows avoiding name clashes with other inspect() methods.
Minutes
Yeah no...
Activity
MylesBorins commentedon Dec 12, 2016
I do want to mention that the only two things we have on the agenda are approvals for
Semver-minorbackports, and a decision about doing anargonminor back to back. All of these should be able to be discussed in an async fashion.If people are up for it I would like to suggest we postpone the meeting and use this thread to discuss the issues above instead.
Thoughts?
sam-github commentedon Dec 12, 2016
Nice :-). I think there was a move to drop the "v"s from the versions to get people used to it before the 8.x release.
Fishrock123 commentedon Dec 12, 2016
MylesBorins commentedon Dec 12, 2016
@Fishrock123 #9139 has landed
¯\_(ツ)_/¯
edit: OH NVM... in a release
... I'll show myself out
Fishrock123 commentedon Dec 12, 2016
Huh? The PR I mean is nodejs/node#8334
That way we don't need two minor releases.
MylesBorins commentedon Dec 12, 2016
@sam-github can you please comment on the difference between nodejs/node#9139 and nodejs/node#8334
edit: from the PR
This discussion is about 9139 not 8334
Fishrock123 commentedon Dec 12, 2016
I don't think they are mutually exclusive. I think if we are going to do a minor in LTS for one we might as well wait and do both.
sam-github commentedon Dec 12, 2016
Unrelated. #8334 is to allow linux distros to not only link against system openssl (which node already supports at configure time), but to also use the system openssl's CA roots instead of the built-in.
I don't see why one would wait for the other.
sam-github commentedon Dec 12, 2016
I'll be looking at 8334 today, though, fwiw.
MylesBorins commentedon Dec 12, 2016
@Fishrock123 I was talking to @sam-github at interactive and it would appear that v4 and v6 are broken for using certain proxies without these CAs, making it difficult to use those version in certain regions.
I almost view it as a bug fix for that scenario
sam-github commentedon Dec 12, 2016
Its no a regression, because its sucked for awhile, but @amarzavery (coincidentally) brought up the difficulties some communites are having using node, I pointed him at my PR. It would be nice to get this out, but if it needs to simmer a bit, I guess they can wait a bit longer for a usable npm.
Fishrock123 commentedon Dec 12, 2016
It will take a while regardless. I don't see what a potential extra couple weeks makes in this case given it'l probably be more than a month out to begin with.
sam-github commentedon Dec 12, 2016
Could be. I heard if this doesn't go in now, then it causes a cascade of even longer delays, but I don't understand the release pipeline ATM.
When are patches released? When minors? Why was the last 7.x a 7.2.1 instead of a 7.3.0? When will the next 6.x and 4.x come out? Will they contain only patches, or minors and patches?
sam-github commentedon Dec 12, 2016
I figured out how the currents work.
For the record, I am not trying to railroad this through. If it doesn't match LTS policy, that's OK. We can wait.
But I do think it is low risk - the code is not invoked if the env var is not set, and high value for a not publically vocal but important subset of node users who are having difficulty, particularly in locked down corporate environments.
alexwhitman commentedon Dec 12, 2016
For what it's worth (and apologies if this isn't the place to weigh in) but I'd like to see it go into 6.x. We have a growing number of Node.js applications with many of them needing to interact with internal systems using certificates signed by our internal CA. The simplicity of adding an extra
Environmentline to our systemd unit file template would be hugely beneficial.MylesBorins commentedon Dec 12, 2016
@alexwhitman fwiw it doesn't appear that there will be an issue get the sign off for it to land. The bigger question is how long it will take to land in particular lines. Following our current procedures it will be able to land in
Boronfaster thanArgondue to the fact thatArgonjust had a semver minor release.sam-github commentedon Dec 12, 2016
Is Boron 8.x?
MylesBorins commentedon Dec 12, 2016
Argon=== 4.xBoron=== 6.xMylesBorins commentedon Dec 12, 2016
@destroyerofbuilds there is no policy, just a general sentiment... most LTS programs do not do minors at all, so we have tried to space ours out
[-] LTS WG Meeting - 2016-12-12 8:00 PM UTC[/-][+](CANCELLED) LTS WG Meeting - 2016-12-12 8:00 PM UTC[/+]MylesBorins commentedon Dec 12, 2016
So I'm going to go ahead and officially call this meeting off.
I've opened #171 to discuss coming up with a more defined policy around these releases. I think we can safely wait on voting on the two changes landing... the more pressing issue is deciding release cadence
Fishrock123 commentedon Dec 12, 2016
Err, haven't we done this with all other minors up to this point? We'd be best to message that and not surprise the rest of the group who may not be involved in this particular conversation.
amarzavery commentedon Dec 12, 2016
We have Azure customers using the azure-cli on mac and Linux. By getting #8334 backported to 4.x this will help our Linux customers. I definitely agree that a general solution for Windows Enterprise customers would be extremely helpful, however it would be great if we can unblock some of our customers at the earliest rather than waiting for a long time.
MylesBorins commentedon Dec 13, 2016
@Fishrock123 that comment was meant as I've already talked to a few individuals from LTS and the stakeholders on the issue. As such I was under the impression there was not going to be much push back. apologies if you think I was a bit ahead of myself there.