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

README.md: note that we'd like to reconcile with node #45

Closed
wants to merge 1 commit into from

Conversation

piscisaureus
Copy link
Contributor

Note that ideally io.js and node.js will come back together one day.
I don't know if this is the right way to say it (or even if it's grammatically correct).

@iojs/tc

@cjihrig
Copy link
Contributor

cjihrig commented Dec 3, 2014

Replace once with one day, and it seems fine.

@bnoordhuis
Copy link
Member

'Reconcile' makes it sound as if there was a painful breakup but I can't really come up with a better word. 'Merge again' or 'team up again' is not really an improvement. LGTM, then.

@mikeal
Copy link
Contributor

mikeal commented Dec 3, 2014

I know that this is based on language I wrote a while back but looking at it now it raises more questions than it answers. What would it take to reconcile? Why aren't they already reconciled? And in order to answer those questions it would have to read like a letter of demands which I don't think anyone wants.

@piscisaureus
Copy link
Contributor Author

@mikeal

I agree that it raises questions but what doesn't. "This is a fork of joyent/node" also raises questions ("why?" for example).

The reason I propose to add this is because we want to make it clear that (at least for now) it's not a fork that will definitely go it's own direction (like mariadb or jenkins). As long as we're actively talking to Joyent, that's not the case. So I would suggest to accept that the statement doesn't answer every question anyone could ever ask, but we still show what our intentions are.

Maybe it would help to put a reference to the node advisory board in here?

@isaacs
Copy link
Contributor

isaacs commented Dec 3, 2014

-1.

The best thing to say in this readme is as little as necessary. Stick to the technical facts. We can discuss hopes and plans and feelings elsewhere.

@mikeal
Copy link
Contributor

mikeal commented Dec 3, 2014

@isaacs I'm gonna created an all new fork where the entire README is my feelings :)

@isaacs
Copy link
Contributor

isaacs commented Dec 4, 2014

@mikeal Call it mr.js and then you can be Mr. JavaScript.

@piscisaureus
Copy link
Contributor Author

I didn't say anything about feelings.

@isaacs
Copy link
Contributor

isaacs commented Dec 4, 2014

Hope is a feeling.

@mikeal
Copy link
Contributor

mikeal commented Dec 4, 2014

Hope is a feeling.

This just got so philosophical.

On Wednesday, December 3, 2014, Isaac Z. Schlueter notifications@github.com
wrote:

Hope is a feeling.


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

@piscisaureus
Copy link
Contributor Author

@isaacs @mikeal
Instead of twisting my words and ridiculing me - can you stay on topic please?

The best thing to say in this readme is as little as necessary.

Why? We should be a clear as possible without producing a massive piece of text.

Stick to the technical facts. We can discuss hopes and plans and feelings elsewhere.

I didn't say feelings. I would like to point out that the line before the one I inserted reads: "We intend to release, with increasing regularity, etc...". I do not see how this is categorically different than mentioning a hope (or whatever, a goal, an ideal) to reconcile with node. It certainly is a plan.

@piscisaureus
Copy link
Contributor Author

If you are against it, that's okay, then tell me what your problem really is.

Maybe you don't want to reconcile with node, or you think it's not important enough to mention in the readme, or you think it should not be widely known?

@rlidwka
Copy link
Contributor

rlidwka commented Dec 4, 2014

Readme does state intentions already (compatibility, release frequency), and "reconciliation" (or, should we say, "upstream merge"?) seems to be one of them.

So, it would be logical to add that.

@isaacs
Copy link
Contributor

isaacs commented Dec 4, 2014

@poscisaureus I apologize, I didn't mean my comments as ridicule at all.

I simply mean that I don't think this is the place to be talking about our plans re Joyent. It's the kind of thing that belongs in a roadmap or blog post.

This is only my opinion. If I'm in the minority here I'm happy to withdraw it. It's not a strongly held opinion.

@rvagg rvagg force-pushed the v0.12 branch 4 times, most recently from d7e65ff to 185d11c Compare December 4, 2014 10:21
@mikeal
Copy link
Contributor

mikeal commented Dec 4, 2014

@piscisaureus I was ridiculing @isaacs because I thought the concept of being "anti-feelings" was funny. I didn't mean to offend you and I apologize if I did.

I'm not opposed to reconciliation, I'm just concerned about what this messaging says about the project. This messaging isn't in a vacuum and the small comments Joyent has made thus far make it sound like they don't agree with a faster pace of progress on the grounds that it hurts stability. If that's the message they're going to pursue going forward I think the strongest messaging we could have is "this is what we believe in and what we are doing." Unlike Joyent we have a clear way that people from Joyent, or anyone else, can get involved in the project and participate in decision making. The reconciliation ball is really in their court and if they aren't talking about it then I think it might be confusing for us to be talking about it.

@cjihrig
Copy link
Contributor

cjihrig commented Dec 22, 2014

Was a resolution ever determined here?

@rvagg
Copy link
Member

rvagg commented Dec 23, 2014

I would say that there is enough negativity about this added language in this thread that it's probably not mergable as is; I suspect that it may be too difficult to come up with satisfactory wording that everyone agrees on and the whole topic of iojs/io.js and joyent/node reconciliation should be left to adjacent blog posts and discussions.

@othiym23
Copy link
Contributor

@rvagg Agreed. This isn't something that needs to be part of the repo itself.

boingoing pushed a commit to boingoing/node that referenced this pull request Apr 6, 2017
 - Add support for property descriptors including accessor callbacks
 - Add a data pointer for function and accessor callbacks
 - Add API for defining a property using a property descriptor
 - Update the constructor API to use property descriptors
ofrobots added a commit to ofrobots/node that referenced this pull request Jan 29, 2019
Original commit message:

  Merged: [wasm] Fix dispatch table instance update

  This CL fixes a bug where the receiving instance was updated improperly
  in the dispatch table(s) of an imported table.

  BUG=chromium:875322
  R=​mstarzinger@chromium.org
  CC=titzer@chromium.org

  Change-Id: Iff24953a1fb6a8ab794e12a7a976d544b56fc3c2
  Originally-reviewed-on: https://chromium-review.googlesource.com/1196886
  No-Try: true
  No-Presubmit: true
  No-Treechecks: true
  Reviewed-on: https://chromium-review.googlesource.com/1212922
  Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
  Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
  Cr-Commit-Position: refs/branch-heads/6.9@{nodejs#45}
  Cr-Branched-From: d7b61abe7b48928aed739f02bf7695732d359e7e-refs/heads/6.9.427@{#1}
  Cr-Branched-From: b7e108d6016bf6b7de3a34e6d61cb522f5193460-refs/heads/master@{nodejs#54504}

Refs: v8/v8@442977e
BethGriggs pushed a commit that referenced this pull request Feb 4, 2019
Original commit message:

  Merged: [wasm] Fix dispatch table instance update

  This CL fixes a bug where the receiving instance was updated improperly
  in the dispatch table(s) of an imported table.

  BUG=chromium:875322
  R=​mstarzinger@chromium.org
  CC=titzer@chromium.org

  Change-Id: Iff24953a1fb6a8ab794e12a7a976d544b56fc3c2
  Originally-reviewed-on: https://chromium-review.googlesource.com/1196886
  No-Try: true
  No-Presubmit: true
  No-Treechecks: true
  Reviewed-on: https://chromium-review.googlesource.com/1212922
  Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
  Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
  Cr-Commit-Position: refs/branch-heads/6.9@{#45}
  Cr-Branched-From: d7b61abe7b48928aed739f02bf7695732d359e7e-refs/heads/6.9.427@{#1}
  Cr-Branched-From: b7e108d6016bf6b7de3a34e6d61cb522f5193460-refs/heads/master@{#54504}

Refs: v8/v8@442977e

PR-URL: #25242
Reviewed-By: Michaël Zasso <targos@protonmail.com>
rvagg pushed a commit that referenced this pull request Feb 28, 2019
Original commit message:

  Merged: [wasm] Fix dispatch table instance update

  This CL fixes a bug where the receiving instance was updated improperly
  in the dispatch table(s) of an imported table.

  BUG=chromium:875322
  R=​mstarzinger@chromium.org
  CC=titzer@chromium.org

  Change-Id: Iff24953a1fb6a8ab794e12a7a976d544b56fc3c2
  Originally-reviewed-on: https://chromium-review.googlesource.com/1196886
  No-Try: true
  No-Presubmit: true
  No-Treechecks: true
  Reviewed-on: https://chromium-review.googlesource.com/1212922
  Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
  Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
  Cr-Commit-Position: refs/branch-heads/6.9@{#45}
  Cr-Branched-From: d7b61abe7b48928aed739f02bf7695732d359e7e-refs/heads/6.9.427@{#1}
  Cr-Branched-From: b7e108d6016bf6b7de3a34e6d61cb522f5193460-refs/heads/master@{#54504}

Refs: v8/v8@442977e

PR-URL: #25242
Reviewed-By: Michaël Zasso <targos@protonmail.com>
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

Successfully merging this pull request may close these issues.

9 participants