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

Discussion: Adding special features to LTS branches #5

Closed
rvagg opened this issue Apr 5, 2015 · 13 comments
Closed

Discussion: Adding special features to LTS branches #5

rvagg opened this issue Apr 5, 2015 · 13 comments

Comments

@rvagg
Copy link
Member

rvagg commented Apr 5, 2015

This might be controversial and perhaps the answer is a simple no. One of the advantages of an LTS branch for companies that are extending Node/io.js is that they have a stable foundation to work on.

Two examples of this are:

  • IBM's extension of Node to support their architectures which aren't (yet) supported by V8, under io.js policy we're not floating significant patches against V8 so probably not acceptable for us to merge in their changes to the standard releases. We're also upgrading too quickly because they'd need to be constantly adapting to new V8 versions with their radical changes, which is painful.
  • Joyent add mdb support to Node.js, but this is a non-trivial exercise and takes quite a bit of effort. I suspect a large part of their reluctance to embrace newer V8 versions or faster V8 upgrade cycles is to do with the difficulty of make it work with mdb.
  • There are others that I'm aware of but the pattern is the same.

With an LTS, we have a stable V8 to work with which makes it easier for companies to use as a foundation for additional changes.

So the question is - do we accept additional features into an LTS branch? If IBM came along with POWER support or Joyent wanted mdb support would we be willing to even discuss it or are these pure base-releases and any extension has to happen in a release channel that they create on top of what we release? The version numbering would obviously be kind of awkward because we're likely talking about feature additions, therefore minor-version bumps, but I'm sure we could get creative with this (maybe we claim the next minor-version bump for an LTS and standard releases have to bump two minor-versions to continue).

Discuss.

@mikeal
Copy link
Contributor

mikeal commented Apr 5, 2015

IBM's extension of Node to support their architectures which aren't (yet) supported by V8

This might not be an issue any longer. PPC support is in latest v8.

Quick question though: will adding support for a new architecture break the ABI on other architectures previously supported?

I also wonder if this is really an issue any longer. For previously unsupported platforms I have to assume that for at least one major release cycle the only people adopting that new platform are "early adopters" if our major release cycles are 6 months or less (which I think is our target).

I think the main reason this has become an issue in node.js is the long release cycles. People are far more compelled to try and get their features in to the previous release line when the cycles are so long.

With an LTS, we have a stable V8 to work with which makes it easier for companies to use as a foundation for additional changes.

This is a double-edged sword because at least part of the stability of that prior release line is the fact that we aren't increasing the surface area for bugs with additional functionality.

@mikeal
Copy link
Contributor

mikeal commented Apr 6, 2015

I just realized that if we only take majors for LTS we have the ability to take on new features if necessary. The only exception to this is feature additions where the ABI changes which we currently avoid in minors for current.

@jasnell
Copy link
Member

jasnell commented Apr 15, 2015

@rvagg : "do we accept additional features into an LTS branch"

I would say definitely no, unless they are necessary to address critical bugs or vulnerabilities. If IBM came along and wanted to add support for one of our platforms and we built that off an LTS release, we would likely handle that particular distribution ourselves rather than asking to have it added to the LTS branch; we would definitely, however, want to see about getting support into master moving forward -- which means us doing the work necessary to maintain support at the current v8 level.

@mdawsonibm -- any additional thoughts here?

@mhdawson
Copy link
Member

I agree that we don't want to be adding "features" to an LTS. We get pushed to do this in more traditional product so I could regret saying this but I still think the starting point should be "no". The only exception would be to address security issues that might have some of the same characteristics of what would normally be considered a "feature"

@rvagg
Copy link
Member Author

rvagg commented Apr 16, 2015

I agree with all of these sentiments, just trying to tease apart the underlying issues.

A more pertinent example might be mdb support by Joyent. Their business model for mdb in Node involves people being able to take an mdb-compatible core dump from a Node progress and uploading it to Manta (or something like that). But mdb support in Node requires a bit of work getting the all the jit symbols in place so you can expose them through the dump. I suspect that one of the reasons they are hesitant to upgrade V8 in joyent/node as quickly as others would like is that rewriting mdb-support each V8 release would be too people-time-intensive. But an LTS release would help with that of course since they have a stable base to build on. However, if they can't bundle in stuff to an LTS branch that doesn't live in a bleeding-edge branch then they are only left with the option of distributing their own LTS-based binaries for people to use.

I'm not saying I want to support this type of model, but it's worth discussing.

@jasnell
Copy link
Member

jasnell commented Apr 16, 2015

I'm sure lots of vendors would love to add those kinds of things into
projects after LTS but it tends to break down and get far too complicated.
This is an argument for giving folks enough time to prepare for new LTS
releases, especially those with major v8 bumps.

Just thinking out loud... Perhaps one way of doing it would be to introduce
a "contrib" mechanism that would allow third parties to essentially float
their own patches. Build config flags could then be used to switch on
specific third party contribs. They would be unsupported by the main
project but would provide a landing area for the additional third party
features. There's just a whole range of issues involved with that also
tho...
On Apr 15, 2015 6:17 PM, "Rod Vagg" notifications@github.com wrote:

I agree with all of these sentiments, just trying to tease apart the
underlying issues.

A more pertinent example might be mdb support by Joyent. Their business
model for mdb in Node involves people being able to take an mdb-compatible
core dump from a Node progress and uploading it to Manta (or something like
that). But mdb support in Node requires a bit of work getting the all the
jit symbols in place so you can expose them through the dump. I suspect
that one of the reasons they are hesitant to upgrade V8 in joyent/node as
quickly as others would like is that rewriting mdb-support each V8 release
would be too people-time-intensive. But an LTS release would help with that
of course since they have a stable base to build on. However, if they
can't bundle in stuff to an LTS branch that doesn't live in a bleeding-edge
branch then they are only left with the option of distributing their own
LTS-based binaries for people to use.

I'm not saying I want to support this type of model, but it's worth
discussing.


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

@ofrobots
Copy link

If the only one building and testing the code in the contrib directory is the vendor, I am not sure it makes a lot of sense for the code to live in the main project.

A little bit tangential, but I haven't seen this discussed elsewhere. How would the trademark policy intersect with vendors shipping their own patched LTS version?

@mhdawson
Copy link
Member

It may also come down to what is considered a "bug". If the support required for mdb in Node was broken by v8 upgrade I don't think I'd be opposed to that being fixed in an LTS release. Some cases where it is too difficult to keep up in master might be addressed by allowing "fixes" to restore earlier functionality.

@jfhbrook
Copy link

jfhbrook commented May 7, 2015

No. No new features. It's way more important that shit doesn't break than it is to get new features into an LTS. BUGFIXES ONLY.

@jfhbrook
Copy link

jfhbrook commented May 7, 2015

A LTR should be so conservative it's physically painful.

@misterdjules
Copy link

I suspect that one of the reasons they are hesitant to upgrade V8 in joyent/node as quickly as others
would like is that rewriting mdb-support each V8 release would be too people-time-intensive

Joyent alone doesn't upgrade V8 in node. The Node.js core team, the contributors and the project makes this decision together.

The core team decided not to upgrade V8 before releasing v0.12.0 because it would have happened too late in the release cycle, and the majority of the team wasn't comfortable with delaying the release even more to give it enough time to be tested properly . If V8 had been upgraded, mdb would have been updated at some point, but it certainly wasn't a reason not to upgrade.

But an LTS release would help with that of course since they have a stable base to build on.
However, if they can't bundle in stuff to an LTS branch that doesn't live in a bleeding-edge branch
then they are only left with the option of distributing their own LTS-based binaries for people to use.

I don't think any change made to mdb_v8 to support changes in V8 would be breaking node in any way. The changes usually add/remove/modify symbols to be generated by gen-postmortem-metadata.py, and change the implementation of mdb_v8 in itself. To me these symbols are private in the sense that they are only used by postmortem debugging tools, and do not constitute an API. Thus, I don't think that any change required to adapt mdb to a V8 upgrade could not be done in a LTS branch/release.

/cc @davepacheco so that he can weigh in and confirm/inform since he's done a lot of the work on mdb.

@davepacheco
Copy link

Yeah, @misterdjules's summary about the mdb work is accurate.

@bnoordhuis
Copy link
Member

The mdb_v8 support won't be an issue if Joyent invests a little more in keeping it up-to-date in upstream V8.

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

9 participants