Reconciliation Proposal #978
Comments
What about Julien, Steven, James, Michael who are now only working on node?
Nit: cound (spelling) |
|
@mikeal Should we notify Node.js of this to get their input? |
The io.js TC is a small subset of the contributors/committers to io.js. I don't know enough about each of these individuals (other than Julien) and their work on node.js to know if they should be added to the TC (also wondering if they want to being that it's another weekly meeting on their schedule). Are these other people committers to node.js? Are they involved in driving the technical direction? I saw that Julien did the 0.12 release though so it's pretty clear that he should be added. |
|
Steven, Michael and I (all from IBM) have recently been accepted as "Apprentice" members of the node.js core. Steven is primarily driving the Ecma-402 enablement, Michael's team is working on the ppc and system z ports, and I am focusing currently on globalization. As I understand it, we will soon have commit rights to node.js, albeit with an obvious need for review as we earn our stripes. Once the foundation tc launches, we would very much like for our status to be retained, allowing us a chance to continue pushing forward with contributions. Each of us have been participating in the development of the node.js post v0.12 roadmap although we admittedly have a ways to go before rising above the "apprentice" level. (and thank you @piscisaureus for thinking of us 👍 ...) |
|
@jasnell thanks! This clears things up. The closest thing to "apprentice contributor" we have would be "collaborator" and that would also give you commit rights. Although it should be noted that all changes are done as pull requests and reviewed in io.js, even changes being made by TC members, and if the CONTRIBUTING.md file from io.js is adopted that policy would remain. In addition to being collaborators it would make a lot of sense to add anyone working on PPC and Z ports to the LTS WG which would be maintaining old V8/node.js lines. Does that sound about right? |
|
ECMA-402 & globalization support actually brings up an interesting issue: io.js hasn't enabled I have strong concerns about some of the work I see going on in joyent/node on this front. I'd like it noted that not only are there concerns on the Joyent side of this about the activity that has gone on in io.js since the fork (stated by Joyent representatives), but there are now also concerns on the io.js side of this about the activity that has gone on in joyent/node. Clearly the longer it takes to find a mechanism for merging, the further the two projects will diverge based on both the amount of activity but also the philosophical and technical direction chosen by the separate parties and this will increase the difficulty of achieving a technical merger. |
|
That sounds about right, yes. |
Maybe we can get concrete here/somewhere? The things that come to mind on my end -
|
|
Ok, added Julien to TC, IBM folks to collaborators and LTS WG. |
|
@rvagg @piscisaureus I think that these technical details should really be figured out by the TC and the LTS WG. New releases of 0.12.x should probably NOT drop support for something they previously supported. The 1.x line is already considered a "breaking change" from 0.12.x so there's no problem not having this stuff there (at least in terms of merging the existing versions). As far as what happens with ICU and SSL in the CURRENT line (1.x), that's up to the TC which would gain 3 new voting members. |
That's okay for now I guess. I would argue it doesn't make much sense to put 3 IBM-ers in the LTS wg. Ee can work this out later as well, e.g. if the IBM folks want to work on something not currently on the roadmap we could just consider the idea and create a separate wg if appropriate. Also having having at least one IBMer join TC meetings would be helpful. |
|
@rvagg We happen to share many of those concerns and would like to see reconciliation happen as quickly and as smoothly as possible. Doing so would benefit the community as a whole. As far as the Ecma402 work that @srl295 has been doing, we are definitely sensitive to the concerns but proper i18n support is a must have for us. It's why we put the work into enabling it. This thread, however, does not seem like the right place to have that particular discussion. At some point, we ought to just get everyone together from both projects and simply lay the technical concerns out on the table and figure out how we're going to resolve them. (btw, If it would help, I've got a conference room in SF we can use to get as many people face to face as we can.) |
|
Wait, @mikeal, do we want to notify node.js? |
|
@mikeal... as @piscisaureus suggests, it would likely make more sense to just have Michael in the LTS wg as it's his team that'll be working on those particular pieces. |
|
@jasnell @piscisaureus updated so that just Michael is in LTS WG. |
|
@joyent/node @iojs/collaborators |
|
We'll need all the working groups to ratify so I'm going to ping them:
|
ghost
mentioned this issue
|
@mikeal I notified joyent/node via nodejs/node-v0.x-archive#9295. |
|
As a member or @iojs/iojs-he I'm fine with moving to Node as long as contributing stays similar to how it is in io.js and the governance model remains open and community driven. |
|
This is a well written and even keeled approach to reconciling the two code bases. The only large question I see here @mikeal is what would happen to That is however, largely a question for @iojs/core and the node.js core folks and I'm sure a reasonable plan will be agreed upon. |
|
Most of this looks good to me. The only point of significant technical divergence at this time seems to be intl. I do not want to see io.js become "node-lite" and joyent/node to become "node-with-intl". It's not a pressing issue blocking merging the projects, but I would like to see some very clear-cut decision made by the TC about whether we're going to ship intl or not. We should not have two different flavors or distros, especially not under the same name; that's even worse than what we have now. The most successful end-game is a single "node" that can make forward progress. What I've heard from Joyent folks is that they'd like to see a clear-cut strategy for long-term support that doesn't leave users behind in the cold. I think that's a fair request, and the LTSWG is working on it. Let's continue that process. Another concern I've heard from Joyent collaborators is that they don't want to be excluded or marginalized before the projects have had a chance to integrate and find common ground. That's also fair, in my opinion. Merging these projects will certainly cause some conflicts, and it's unlikely that anyone will be able to collaborate in good faith if they're busy watching their backs for political maneuvering. I've suggested in the past a temporary moratorium on expelling anyone from the TC for some reasonable period of time as a way to address that concern, but there may be other strategies as well. From what I've seen and heard in the foundation setup, they do want the TC to be self-governed, and protected from undue influence by the executive board. However, they also want to make sure that the project won't be hijacked immediately in bad faith, which is why we've heard suggestions of specific TC governance rules being set on day 1, some of which are significantly different from the io.js tc, and some of which (like requiring strict consensus for every TC decision) I personally believe will be extremely problematic and likely to stall progress. At the last JNAB meeting, there was a suggestion of getting the io.js TC and the node foundation folks together to discuss this. I think that's a good idea, but also sent out some homework questions to hopefully prime the discussion in an empathetic and collaborative direction. Hopefully we won't just get in a room and talk past each other for hours. |
I understand that this is a concern but I find it somewhat unwarranted. The process is too transparent for a set of people to successfully cut someone out in bad faith without significant negative consequences for those people and the project as a whole. Additionally, I would expect that those who are significantly invested in concerns over the stability of prior releases and LTS to be members of the LTS WG which is just being created and, being that it will mostly be involved in 0.12, I would expect it to be dominated by node.js contributors, at least at first. Anyway, if all of this isn't enough to alleviate concerns then we can consider some period of time where people cannot be removed from the TC. That said, we can't mint membership entirely or guarantee seats for too long, considering how fast the project has grown and how much we've needed to adjust as we've gone we don't want to mint anything for too long. |
I 100% agree with you that strict consensus (i.e. veto) will be very problematic for getting things done from the technical perspective. What other significant differences are there? I've lost track of where the JNAB minute notes get posted. |
I'm gonna go out on a limb and say that strict consensus for any part of decision making is a deal breaker. If an argument breaks down and we can't reach an agreement it isn't acceptable to just do nothing and grind to a halt and we already know that is where strict consensus can lead for this exact group of people. The consensus seeking model is working tremendously well. If we're worried that the voting fallback (which we've never actually had to use BTW) is too permissive for certain decisions we can consider upping the majority necessary to 60%. |
|
I'd like to see Intl added in as a single language by default then allow the end user to compile in all the languages that they want or hot load them on the fly. We are very excited to be able to use Intl for all of the languages that we have to support 😄 |
|
Like others said, the plan looks reasonable and promising, and @iojs/iojs-uk group will definitely support its current version or any modified version that still follows the spirit of the original proposal. We are interested in promoting and expanding Node-the-ecosystem and strongly believe that the unified project will benefit everyone. Regarding Intl we support having it build into Node. Ukrainian is a distinctive Slavic language with non-Latin alphabet, distinct collation rules, etc. The target audience of our group are people who use Ukrainian to learn programming in general, JavaScript and Node in particular, and who are very likely use it to use Ukrainian in their software. The fact that many language-specific features will just work is very valuable. We don't think it should be a separate module on npm, though. Ecma402 defines the standard I18n API with globals, and we would expect Node to behave this way, too. Ultimately, both Node.js and iojs today claim to be JavaScript platforms, and global If it can be a some kind of magic module, then so be it. However, if a person would have to download it and/or update it separately, then we'd likely repeat the mistake JVM made with an isolated copy of tzdata. JVM's tzdata can be updated separately from a system-wide one. Most developers and admins, however, don't bother with it. As a result most Java deployments out there have an up-to-date system-wide tzdata that is completely ignored by the JVM, which instead uses an obsolete version. Speaking of binary sizes I suspect that most major operating systems have i18n libraries and APIs build in. We could potentially link to those instead of forcing users to download ICU every time they update Node. Of couse there are certain situations when having Intl enabled is undesirable, for example for Raspberry Pi builds. However, in our opinion not having Intl should be a deliberate choice. I18n should be opt out, not opt in |
To me it's still unclear what benefits a merger with node.js would have. This issue appears to be more focused on the how of a merger, and less on the why. Is there an overview where the benefits / costs of merging with node.js are outlined? If there's not, I'd be curious to know what the view of the io.js TC and collaborators is on this (possibly in separate issue, if this is not the right place for it). Thanks! |
The point was to have open collaboration to help move node forward. That has and will continue to happen. :)
Why did most of the existing collaborators move (and want to move) the majority of their efforts here then? |
So where is this hard work? Which repo? An opensource project, surely there are some commits somewhere? |
Why would we stop development and why would it be technical debt? If you'd read the actually reconciliation proposal you'd see that the different version lines from both io.js and node.js would remain intact.
This is simply not true. Contributions to node.js were at an all time low when we forked and releases had slowed to almost zero. You don't have to take my word for it, you can look at the contribution graphs and the release timelines. Yes, there were "people working on node the whole time" and most of those people were the initial contributors to io.js :) Anyway, this line of complaint is not actually productive. We have a proposal for reconciliation, we have a proposal for open governance in the advisory board we're working on. joyent/nodejs-advisory-board#30 Things are progressing nicely toward a reconciliation and there is no need to stop development of io.js waiting for those to complete. I honestly don't know where that hostility came from but it seems very misplaced. |
|
After processing the first round of comments, a draft charter has been landed in joyent/nodejs-advisory-board@0609b04. Mikeal is now making an attempt to add "support" for working groups to the foundation's technical governance documents: joyent/nodejs-advisory-board#33. |
|
thanks @piscisaureus |
So, does it means that CANARY v8 version merges will be available on some sort of node 1.x-canary stable builds only after testing? It would be great if there was a second diversion on node's canary releases such as Couldn't it allow CURRENT and CANARY to have similar releases, or even the same? That would allow: Versions: Non-versions: |
It is obvious that you know very little (or nothing!) about what V8 actually is and what importance it plays in node. You don't really seam to grip how open source works either. Sad. |
|
Closing this in favor of #1664 |
@mikeal The new foundations trademark policy contains the following text
Could you explain why the trademark ownership was never transferred? The new policy seems just as problematic as the previous one, which as I understand it caused the whole iojs/node split in the first place. |
(There might be a 3? I forget.) Edit: Also it wasn't the actual cause of the split. Poor project management would be closer to the actual reason. |
|
|
+1 @Fishrock123, @feross |
|
I am absolutely nobody here. Just giving my humble 2c
Keeping the trademark, a crucial part of node, would be "leasing node to the foundation", rather than "giving it to the foundation". |
|
|
^ cc @mikeal, @piscisaureus, & @rvagg I guess. |
|
Sure, transferring an asset is simple but this is an asset that has been on the books of a company for 5 years while it has done all the things you would expect it to do (raise money, acquire lines of credit for hardware, etc). Joyent is not in a position where it can transfer the ownership of the mark (I'm sure they'd prefer it as the way the deal has to be structured they are stuck with the legal bill of enforcement while the foundation administers the conditions of use). I share the concerns around prior arrangements of this nature but you'll notice that many of the companies you note were unhappy with prior arrangements are members of the Node Foundation and they worked hard to make sure this arrangement did not have the same problems prior arrangements did. I'm not a lawyer, but I'm confident that the lawyers from companies suffering from prior arrangements did a good job of protecting us from those same problems. That doesn't mean we might not have new problems of our own some day, but I'm not worried about having the same problems you've noted.
The new policy allows the foundation (an independent body, not a single company) to approve uses of the mark. That is much different from the previous policy. If you're looking for a policy that doesn't require any approval for uses of the mark I'm afraid you're out of luck as trademark law doesn't really allow that. The io.js fork was primarily motivated by governance issues. Joyent had full control over governance changes because it owned the assets (domain name, trademark, etc) so you could say the trademark was a part of that but the much bigger issue was that the contributors to node.js weren't in a position to run node.js. That has been resolved. Also note that the other assets (domain name, twitter handle, etc) should be transferred to the foundation outright. |
👏 |
|
Just to echo Mikeal's remarks: the new trademark policy grants the
|
|
@jasnell Are you saying that the reasons why the trademark isn't transferred is for the language referencing the trademark, where Joyent is perpetually included? I am asking because all Mickeal mentioned was the difficulty in handing it over, rather than the wording of the reference to the trademark that will "respectfully" include Joyent. I think it's great that Joyent started node, and that their name will be in history no matter what. |
|
No, I'm not saying that was the reason ownership wasn't transferred, just
|
|
The reason you have to, in very few but noticeable circumstances, put a trademark notice referencing the owner is due to trademark law itself. In some scenarios if you were allowed to do that without a notice the mark would in danger of being considered "generic" and would be lost to all of us. The reason the notice says "is a trademark of Joyent" is because it is still owned by Joyent even though it is administered by the foundation. |
Not so much 'started' as 'acquired'. They have a great PR department though. |
|
@jasonwilliams200OK I just noticed your comment addressed to me (for some reason GitHub did not notify me, or I missed the notification). You wrote:
The above is not quite correct. One of the comments in which I provided a significant bit of my thoughts was indeed deleted, albeit not by me. I do not recall by whom, but it was likely someone moderating this issue/discussion and I am perfectly fine with that. However, I cannot have a discussion reflect a partial view of what I had written. Consequently I removed the rest of my comments. This has nothing to do with appreciativeness. I appreciate the effort every node contributor puts into all aspects of building node. |
and others
A lot of questions have been coming our way about what a merger of the node.js and io.js projects might look like. People in both projects want to know their work won't be thrown away and that we can preserve the positive aspects of each project.
This is a draft and will be continually updated and edited based on input from the community. It is not an ultimatum to Joyent or The Node.js Foundation but rather a collaboration point for the io.js community to produce a proposal for merging.
This document uses the terms io.js and node.js to refer to those projects prior to a merge and Node to refer to a future merged project.
While io.js is often used as a starting point this document treats a future project under the foundation as a new organism made from the merger of each project and not as an extension of only node.js or only io.js. The goal of the merger should be a project that is actually greater than the sum these parts.
Technical Governance
The Node.js Foundation would adopt, as it's Technical Governance Structure (which is distinct and seperate from the foundation governance structure), a very simple structure which would ensure the following:
Because foundation bylaws are quite difficult to change and the TC wishes to make continued iterative improvements to its structure it would be a mistake to bake the entire governance structure as it exists today in to the foundation bylaws.
As an initial agreed upon structure, beyond what is in the bylaws, the following documents would be adopted from io.js.
In addition to the definition of "collaborator" from CONTRIBUTING.md the list of existing collaborators to io.js would also transfer.
The following changes would be made to these documents prior adoption:
Long Term Support
High level ideas about LTS are addressed in the io.js roadmap but it lacks specifics because io.js has not yet produced a release that breaks compatibility with prior releases which would cause it to begin executing on this plan. The node.js project has an informal Long Term Support policy which is not formally documented but it does produce patch releases for prior versions so we can assume some policy does exist.
LTS WG (Long Term Support Working Group)
The following is a draft charter for the LTS WG which would be added to WORKING_GROUPS.md.
The LTS WG is responsible for maintenance and releases of prior versions of Node.
Node produces patch releases of prior versions for as long as community members are willing to maintain them. The LTS WG is responsible for when it no longer has the contributions necessary to support a particular version.
The LTS WG's responsibilities are:
changes to prior releases (not CURRENT or CANARY).
Initial Members would include
Note that specifics around managing branches is left out of the
charter but is part of the responsibilities for the working group under the last
bullet point.
Versions Merger
Because there is currently no overlap between io.js and node.js versions we can, and in fact must, consider all versions of both projects as now being versions of Node. If we did not we would unnecessarily break a large portion of the community that depends on these versions.
Prior Releases
The following versions are considered "prior releases" and are under the control of the LTS WG>
It should be noted that while 1.0+ releases follow semver versions prior to 1.0 did not and it is at the discretion of the LTS WG whether or not they would like to take API additions in to 0.12.x and 0.10.x patch releases. However, backwards incompatible changes cannot be made to these releases in following with the existing policies of both node.js and io.js.
Current Release
As it stands there are two CURRENT development lines: node.js 0.12.x and io.js 1.x. Development, in some form, will need to continue on both of these lines as different users depending on each line. The question then becomes "which line do we put in to LTS?"
In the last few months io.js has made huge gains in part due to the fact that it aligned its current stable line of development with that of its dependencies. That, along with a faster release cycle, has also brought many module authors in to core and so the ecosystem is beginning to also align its current stable development with that of core. This has ushered in a new era of collaboration between projects and the larger community which Node should continue.
This does not, however, mean that 0.12.x is a "dead" line. Far from it, 0.12.x and 0.10.x are still in use by many users and it will be the work of the LTS WG to continue to ensure those users have a stable and supported platform.
Non-Versioned Releases
CANARY ("next" V8 and any changes marked as major)
Along with the current stable line of development there should be a future line. This line exists as a branch and non-versioned nightly builds for testing. It is a testing ground for changes to Node that would necessitate bumping its major version as well as for testing the CANARY version of V8.
Just as we have done with current stable, the "next" line of Node development should align with that of its dependencies. This allows the project and its users to easily test for performance regressions and potentially breaking changes in those dependencies while active development is still occuring and long before they land in a stable version of Node.
Website
The nodejs.org website would transfer to the Website WG and become the responsibility of that working group. The website will be retooled similar to iojs.org (gulp builds) so that it can be localized by the various language communities from io.js.
Social Media
The social media accounts (Twitter, Facebook, etc) will transfer to the Evangelism WG.
Evangelism WG
This io.js WG will move to Node (pending a vote by the WG) and continue to produce weekly updates, social media engagement, etc, for the Node project.
i18n
All io.js language community working groups (32 individual teams by last count) will vote to
move to the Node project where they would continue to be endpoints for community members to
collaborate with each other in their language of choice and produce localizations of project resources.
Roadmap WG
This io.js WG will move to Node (pending a vote by the WG) and continue to draw in feedback
from users and draft roadmap materials for consideration by the TC.
Streams WG
This io.js WG will move to Node (pending a vote by the WG) along with
readable-streamand will continue to define and improve streams in Node.Tracing WG
This io.js WG will move to Node (pending a vote by the WG) and continue to improve the transparency of Node applications.
Build WG
This io.js WG will move to Node (pending a vote by the WG) and continue to maintain and improve the build infrastructure and produce Node builds.
The text was updated successfully, but these errors were encountered: