Join the Node Foundation?

[mikeal]

All the documentation for the Node Foundation is ready:

• TSC Charter (Basic Governance)
• Development Policy
• Convergence Plan
• Project Lifecyle (Working Groups Definition)
• WG Merger (List of working groups and how they will be merged)

The gist of it is, the foundation's governance structure is nearly identical to io.js'. In fact, during the process of writing all this down we improved the documentation for most of these policies and made some improvements. The new "converged" node project will begin with io.js master and port changes from node.js in for its first release target.

I wrote an extensive piece on why I think we need a foundation, and why I think the structure the Linux Foundation has setup for the Node Foundation is ideal.

It's now time to make a real decision about moving io.js in to the foundation and, eventually, merging with node.js.

Once we've committed to this we would:

• Rename the GitHub org to "node" or "node-foundation" or whatever.
• Continue releasing io.js while the convergence work is happening.
• Move the TC calls to be TSC calls with the entirety of the TSC (we may have to switch to GoToMeeting because of the size)
• Move the node-convergence repo to the new org as "node"

There's obviously going to be a lot of technical work after that continuing to release io.js until a converged release is ready, targeting the new repo for additional automation, etc, but the immediate steps would be the ones I've outlined above.

For the Working Groups, they would continue to do things as io.js (although the org is renamed) until they have access to the appropriate node.js assets and they decide as a WG to shift their focus.

PS. As a point of process, Working Groups are autonomous, so if the TSC decides to move io.js to the Node Foundation but a WG, for whatever reason, declines they would have to be moved out of the foundation org after the move. This is just a limitation of having to move the org.

[Amorelandra]

👍 I am still reading through all of the details, but this looks very sensible and well thought out. Thank you for this.

I am in support.

[Amorelandra]

👍 I am still reading through all of the details, but this looks very sensible and well thought out. Thank you for this.

I am in support.

[benjamingr]

If this is going to work it's going to be amazing. We want to make sure as few users as possible have their projects broken during the transition.

[benjamingr]

If this is going to work it's going to be amazing. We want to make sure as few users as possible have their projects broken during the transition.

[voodootikigod]

Yes. This should be done.

[voodootikigod]

Yes. This should be done.

[djensen47]

👍

[djensen47]

👍

[Qard]

👍 from me.
On May 8, 2015 5:30 PM, "Dave Jensen" notifications@github.com wrote:

[image: 👍]

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

[Qard]

👍 from me.
On May 8, 2015 5:30 PM, "Dave Jensen" notifications@github.com wrote:

[image: 👍]

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

[LongLiveCHIEF]

+1

[LongLiveCHIEF]

+1

[aheckmann]

👍

[aheckmann]

👍

[aredridel]

So far, big 👍

[aredridel]

So far, big 👍

[Planeshifter]

👍

[Planeshifter]

👍

[cjihrig]

👍 I think this is best for everyone.

[cjihrig]

👍 I think this is best for everyone.

[luke-john]

Hey, so whilst the TSC Charter looks pretty good, the actual foundation charter/bylaws are still nowhere public that I've been able to find.

Shouldn't they be available to consider before people vote on joining this foundation?

[luke-john]

Hey, so whilst the TSC Charter looks pretty good, the actual foundation charter/bylaws are still nowhere public that I've been able to find.

Shouldn't they be available to consider before people vote on joining this foundation?

[mscdex]

This may sound nit-picky, but IMHO it'd be best if we could stay with a live TSC meeting stream, even if it's not youtube. The live stream allows people to join IRC and ask questions during and at the end of the meeting. Even though there haven't been that many questions at the TC meetings yet, if we publicized this "feature" more, I think we might get more questions?

[mscdex]

This may sound nit-picky, but IMHO it'd be best if we could stay with a live TSC meeting stream, even if it's not youtube. The live stream allows people to join IRC and ask questions during and at the end of the meeting. Even though there haven't been that many questions at the TC meetings yet, if we publicized this "feature" more, I think we might get more questions?

[Amorelandra]

While I laud the effort to make things as transparent as possible, I think it's unnecessary (possibly harmful) to require that every TSC member be willing to be subject to a live stream every time there is a meeting to be had.

I believe maintaining minutes should be more than sufficient.

[Amorelandra]

While I laud the effort to make things as transparent as possible, I think it's unnecessary (possibly harmful) to require that every TSC member be willing to be subject to a live stream every time there is a meeting to be had.

I believe maintaining minutes should be more than sufficient.

[mscdex]

@emilyrose AFAIK the GotoMeetings are already being recorded, just like the TC meetings are archived on Youtube. The difference however is that GotoMeeting can't do live streaming (too).

[mscdex]

@emilyrose AFAIK the GotoMeetings are already being recorded, just like the TC meetings are archived on Youtube. The difference however is that GotoMeeting can't do live streaming (too).

[Fishrock123]

to require that every TSC member be willing to be subject to a live stream every time there is a meeting to be had.

Usually we have a brief time before anyone wants to discuss anything not publicly, does that help?

[Fishrock123]

to require that every TSC member be willing to be subject to a live stream every time there is a meeting to be had.

Usually we have a brief time before anyone wants to discuss anything not publicly, does that help?

[RnbWd]

👍

[RnbWd]

👍

[comprehendreality]

👍

[comprehendreality]

👍

[brucebentley]

👍🏻 from me as well. The docs & process look solid & I think it's probably about as appropriate a time as ever to make this happen.

Would be much less transparent of the two strayed further away from each other.

[brucebentley]

👍🏻 from me as well. The docs & process look solid & I think it's probably about as appropriate a time as ever to make this happen.

Would be much less transparent of the two strayed further away from each other.

[blitzprog]

👍

[blitzprog]

👍

[carpii]

I don't want to see io and node completely diverge, but personally I cant help thinking joining a foundation seems a touch premature. Admittedly it seems I'm in the minority.

It felt to me like io had an opportunity to achieve so much more in the short term - free from the constraints of politics and a 'foundation' environment - even if this isn't sustainable long term
Clearly a unified node and io platform is better for everyone ultimately, I just wish it wasn't happening quite so soon.

It does seem like Joyent have seen which way the wind is blowing, and decided to open up rather than be sidelined. Nothing wrong with that I suppose, I just hope the foundation finds the right blend of staff and skillsets (which I don't think node.js team quite managed)

[carpii]

I don't want to see io and node completely diverge, but personally I cant help thinking joining a foundation seems a touch premature. Admittedly it seems I'm in the minority.

It felt to me like io had an opportunity to achieve so much more in the short term - free from the constraints of politics and a 'foundation' environment - even if this isn't sustainable long term
Clearly a unified node and io platform is better for everyone ultimately, I just wish it wasn't happening quite so soon.

It does seem like Joyent have seen which way the wind is blowing, and decided to open up rather than be sidelined. Nothing wrong with that I suppose, I just hope the foundation finds the right blend of staff and skillsets (which I don't think node.js team quite managed)

[Qard]

@emilyrose I disagree. If anything, I think everyone involved should want their progress and discussion to be public.

It's because of this transparency that io.js has been able to so rapidly grow. People can follow along, learn what direction we are driving the project in, ask questions about things they don't understand and get positive responses to their questions. That feedback loop is what drove node, and now io.js, to be so popular in the first place.

I think we need to stay vigilant about involving the community in every part of the evolution of the project. We need to keep cycling new faces into the leadership positions, and that's going to be hard if people feel like they are just sitting on the sidelines and not actually getting involved themselves. I very strongly believe we need to do everything in our power to maximise transparency and community involvement.

[Qard]

@emilyrose I disagree. If anything, I think everyone involved should want their progress and discussion to be public.

It's because of this transparency that io.js has been able to so rapidly grow. People can follow along, learn what direction we are driving the project in, ask questions about things they don't understand and get positive responses to their questions. That feedback loop is what drove node, and now io.js, to be so popular in the first place.

I think we need to stay vigilant about involving the community in every part of the evolution of the project. We need to keep cycling new faces into the leadership positions, and that's going to be hard if people feel like they are just sitting on the sidelines and not actually getting involved themselves. I very strongly believe we need to do everything in our power to maximise transparency and community involvement.

[formula1]

@emilyrose tbh, the tc meetings made me feel like I knew the developers better. Its also pretty interesting the descrepency between timezones and not everyone shows up all the time. I get to peek for the first time in my life what its like to work on a team where everyone is an allstar and pushing for progress. Seeing people just brutally honest saying "I didn't do anything" makes it that much better. They are there for a reason and at times life and other things get in the way. I have thoroughly enjoyed hearing them and am trying to make it a regular thing at my workplace.

https://github.com/joyent/nodejs-advisory-board/blob/master/governance-proposal/WG-Merger.md

Streams and Tracing working group have broken links. Streams is probably one of the most important differences between the two projects since iojs went with Isaacs Readable stream if I recall correctly.

I'm actually quite suprised how much pull you guys have. The interesting part to me however was TSC charter

The Board will set the overall TSC Policy.

This can also mean that these docs/charters are temporary.

The Board may additionally make amendments to the TSC charter at any time, though the Board will not interfere with day-to-day discussions, votes or meetings of the TSC.

Technically major changes to the charter will allow the interference. Though that is a cute example, the implications are much bigger.

No more than one-fourth of the TSC members may be affiliated with the same employer.

Techinically Mozilla and Google are different companies. But many of us are fully aware of who pays some of mozillas bills. A more brutal example is something like Comcast/TWC merger where the two companies have no desire to compete but do so by law. So the employer restrictions still allows possible conflict of interest leading to a 50%. I would argue voting rights to employers should be based on how much they have contributed recently however cannot vote on what they are associated with. However your version is much more straight forward.

Outside of this its really incredible how much power you guys have. At the end of the day, the person who pays the bills ought to have the most say so I don't necessarilly question things too much. Though when it comes down to it, if things go down hill maybe we can see another fork. Doubtful though

Edit: +1

[formula1]

@emilyrose tbh, the tc meetings made me feel like I knew the developers better. Its also pretty interesting the descrepency between timezones and not everyone shows up all the time. I get to peek for the first time in my life what its like to work on a team where everyone is an allstar and pushing for progress. Seeing people just brutally honest saying "I didn't do anything" makes it that much better. They are there for a reason and at times life and other things get in the way. I have thoroughly enjoyed hearing them and am trying to make it a regular thing at my workplace.

https://github.com/joyent/nodejs-advisory-board/blob/master/governance-proposal/WG-Merger.md

Streams and Tracing working group have broken links. Streams is probably one of the most important differences between the two projects since iojs went with Isaacs Readable stream if I recall correctly.

I'm actually quite suprised how much pull you guys have. The interesting part to me however was TSC charter

The Board will set the overall TSC Policy.

This can also mean that these docs/charters are temporary.

The Board may additionally make amendments to the TSC charter at any time, though the Board will not interfere with day-to-day discussions, votes or meetings of the TSC.

Technically major changes to the charter will allow the interference. Though that is a cute example, the implications are much bigger.

No more than one-fourth of the TSC members may be affiliated with the same employer.

Techinically Mozilla and Google are different companies. But many of us are fully aware of who pays some of mozillas bills. A more brutal example is something like Comcast/TWC merger where the two companies have no desire to compete but do so by law. So the employer restrictions still allows possible conflict of interest leading to a 50%. I would argue voting rights to employers should be based on how much they have contributed recently however cannot vote on what they are associated with. However your version is much more straight forward.

Outside of this its really incredible how much power you guys have. At the end of the day, the person who pays the bills ought to have the most say so I don't necessarilly question things too much. Though when it comes down to it, if things go down hill maybe we can see another fork. Doubtful though

Edit: +1

[rvagg]

re live streaming, there are a few things worth noting about how we've been conducting these in io.js that may alleviate any concerns:

1. as @Fishrock123 pointed out we usually have a private time beforehand if there are sensitive things to discuss, this time can be used to bring things up that members may not feel comfortable talking about in public although we do tend to push as much as possible into public broadcast to retain the integrity of the process
2. most meetings are just avatars talking to each other, there's no reason to show video, something I appreciate at 6am after I've rolled out of bed!
3. there is a chat channel in the hangouts that can be used as a side-channel, in the past we've had meetings where one party has audio difficulties and we've relayed communication via the chat channel into the public broadcast, there's no reason this couldn't be extended to people who may feel uncomfortable being broadcast.

I'm +1 on addressing any concerns that people may have about making this comfortable so we can include as many quality people as possible and not restrict it to just those who are brave enough to be broadcast. We could document some of these things to make it less intimidating. Alternatively when we're approaching new potential members we could make these things clear then--that process of asking people if they want to be involved is actually a great chance to address concerns and I've had the chance to do that already with new members we've invited in.

[rvagg]

re live streaming, there are a few things worth noting about how we've been conducting these in io.js that may alleviate any concerns:

1. as @Fishrock123 pointed out we usually have a private time beforehand if there are sensitive things to discuss, this time can be used to bring things up that members may not feel comfortable talking about in public although we do tend to push as much as possible into public broadcast to retain the integrity of the process
2. most meetings are just avatars talking to each other, there's no reason to show video, something I appreciate at 6am after I've rolled out of bed!
3. there is a chat channel in the hangouts that can be used as a side-channel, in the past we've had meetings where one party has audio difficulties and we've relayed communication via the chat channel into the public broadcast, there's no reason this couldn't be extended to people who may feel uncomfortable being broadcast.

I'm +1 on addressing any concerns that people may have about making this comfortable so we can include as many quality people as possible and not restrict it to just those who are brave enough to be broadcast. We could document some of these things to make it less intimidating. Alternatively when we're approaching new potential members we could make these things clear then--that process of asking people if they want to be involved is actually a great chance to address concerns and I've had the chance to do that already with new members we've invited in.

[yadakhov]

👍

[yadakhov]

👍

[zeusdeux]

👍 for convergence as well as live streaming (<- this, yes!)

[zeusdeux]

👍 for convergence as well as live streaming (<- this, yes!)

[garthk]

Exciting. Go for it.

[garthk]

Exciting. Go for it.

[sintaxi]

Thanks for putting this together and for everyones hard work coming up with a potential solution.

👍 I am in favour of convergence.

[sintaxi]

Thanks for putting this together and for everyones hard work coming up with a potential solution.

👍 I am in favour of convergence.

[YurySolovyov]

I think it is possible to re-stream meetings to youtube from someone who is attending.
+1 btw.

[YurySolovyov]

I think it is possible to re-stream meetings to youtube from someone who is attending.
+1 btw.

[Zolmeister]

+1

[Zolmeister]

+1

[neurosnap]

👍

[neurosnap]

👍

[blakev]

Which side is caving to the other to conclude in a "foundation?"

It took all of a few months to branch out, do something great, then re-merge with the same people that made it bad in the first place. My involvement only goes as far as reading changelists and running the installer, but it seems like kind of a cop-out.

[blakev]

Which side is caving to the other to conclude in a "foundation?"

It took all of a few months to branch out, do something great, then re-merge with the same people that made it bad in the first place. My involvement only goes as far as reading changelists and running the installer, but it seems like kind of a cop-out.

[rlidwka]

-1 for joining the foundation under these conditions before all nodejs changes are merged.

I don't like a policy "commit to joining first, resolve merge conflicts later" with a requirement that "all changes should be merged".

This approach could backfire. I don't follow node.js development closely this year, but I could easily imagine that they could've added features that would be rejected in io.js now. When/if that happens, io.js would already be committed to merge.

It's even worse: after io.js joins the foundation, node.js development team will have an opportunity to add any changes to node.js that will be merged into io.js later. And we can't back off on that.

I see only two acceptable ways to deal with a code base merge:

1. make a new repository to perform merge, and only after merge is complete, join the foundation
2. join a foundation with io.js code as is, and make all node.js changes as PRs to a new repo with no guarantee of merging (although those changes would be reviewed by a merged TSC)

[rlidwka]

-1 for joining the foundation under these conditions before all nodejs changes are merged.

I don't like a policy "commit to joining first, resolve merge conflicts later" with a requirement that "all changes should be merged".

This approach could backfire. I don't follow node.js development closely this year, but I could easily imagine that they could've added features that would be rejected in io.js now. When/if that happens, io.js would already be committed to merge.

It's even worse: after io.js joins the foundation, node.js development team will have an opportunity to add any changes to node.js that will be merged into io.js later. And we can't back off on that.

I see only two acceptable ways to deal with a code base merge:

1. make a new repository to perform merge, and only after merge is complete, join the foundation
2. join a foundation with io.js code as is, and make all node.js changes as PRs to a new repo with no guarantee of merging (although those changes would be reviewed by a merged TSC)

[formula1]

@blakev that was something I was thinking about as well. However, they want market share and its easiest way to essentially become node rather than competing with no promises of ever being considered as first choice. Also there's something to be said for this being the plan in the first place. One of the first posts I read was from bert which basically said, "we are upset but want to merge again one day". This was the plan all along so only node is caving technically.

[formula1]

@blakev that was something I was thinking about as well. However, they want market share and its easiest way to essentially become node rather than competing with no promises of ever being considered as first choice. Also there's something to be said for this being the plan in the first place. One of the first posts I read was from bert which basically said, "we are upset but want to merge again one day". This was the plan all along so only node is caving technically.

[mscdex]

I agree with @rlidwka, it does seem kind of backwards to have to join first and then work out (code) merge issues. Even though we may have a good general idea of what's unique to node.js and what's unique to io.js, there could be some changes (obvious or not) that end up causing issues during the merge. I think it's best to iron out any of those problems before joining the foundation.

[mscdex]

I agree with @rlidwka, it does seem kind of backwards to have to join first and then work out (code) merge issues. Even though we may have a good general idea of what's unique to node.js and what's unique to io.js, there could be some changes (obvious or not) that end up causing issues during the merge. I think it's best to iron out any of those problems before joining the foundation.

[q2dg]

I agree with option 2 from @rlidwka

[q2dg]

I agree with option 2 from @rlidwka

[mikeal]

@rlidwka @mscdex I don't agree. First of all, we're starting with io.js master. Then we're working towards a new release that takes in the new features from node.js and it makes sense to do that as a combined TSC.

Additionally, those changes to core will follow the same process they have already done in io.js, first the colloborators review and if controversial the change is elevated to the TSC, and in both of those groups people from io.js have a majority.

It doesn't make sense to have two governing bodies (io.js TC and node.js core) pick apart each of these diffs separately, the entire governance process we've designed is there to facilitate cooperation.

It's not a healthy to say "you go make all these changes to merge the project and we, without your input, will decide what we like and what we don't like." That isn't cooperation, and we're going to be cooperating for the foreseeable future.

[mikeal]

@rlidwka @mscdex I don't agree. First of all, we're starting with io.js master. Then we're working towards a new release that takes in the new features from node.js and it makes sense to do that as a combined TSC.

Additionally, those changes to core will follow the same process they have already done in io.js, first the colloborators review and if controversial the change is elevated to the TSC, and in both of those groups people from io.js have a majority.

It doesn't make sense to have two governing bodies (io.js TC and node.js core) pick apart each of these diffs separately, the entire governance process we've designed is there to facilitate cooperation.

It's not a healthy to say "you go make all these changes to merge the project and we, without your input, will decide what we like and what we don't like." That isn't cooperation, and we're going to be cooperating for the foreseeable future.

[mikeal]

join a foundation with io.js code as is, and make all node.js changes as PRs to a new repo with no guarantee of merging (although those changes would be reviewed by a merged TSC)

This is essentially what we're doing but with a slightly varied ordering. We start with io.js master, merge the work from node.js over, then prior to the first release people can propose changes as PRs (including reversions). We talked about this on the last convergence call and backed off of the whole "just merge everything and release" strategy but we did agree that the removal of functionality priorly available in either io.js or node.js would need to be removed as a removal rather than as a challenge to the merge PRs.

[mikeal]

join a foundation with io.js code as is, and make all node.js changes as PRs to a new repo with no guarantee of merging (although those changes would be reviewed by a merged TSC)

This is essentially what we're doing but with a slightly varied ordering. We start with io.js master, merge the work from node.js over, then prior to the first release people can propose changes as PRs (including reversions). We talked about this on the last convergence call and backed off of the whole "just merge everything and release" strategy but we did agree that the removal of functionality priorly available in either io.js or node.js would need to be removed as a removal rather than as a challenge to the merge PRs.

[nodebotanist]

From a less technical perspective: we just had an interesting online discussion as a whole on diversity concerns. Will any of these be taken into account by this merge?

Frankly, I have less trust in the Node community caring about diversity in leadership than I do the IO.js community right now. And I guess a lot of that is because Node has a longer history to stare down, and IO has relatively little.

But, just to put my two cents in, what I'd really like to see from the Node foundation before I let myself get too excited is a plan-- a concrete, distinct, descriptive plan-- to make people feel safe and welcome contributing to Foundation projects, be that in code, writing, or community.

[nodebotanist]

From a less technical perspective: we just had an interesting online discussion as a whole on diversity concerns. Will any of these be taken into account by this merge?

Frankly, I have less trust in the Node community caring about diversity in leadership than I do the IO.js community right now. And I guess a lot of that is because Node has a longer history to stare down, and IO has relatively little.

But, just to put my two cents in, what I'd really like to see from the Node foundation before I let myself get too excited is a plan-- a concrete, distinct, descriptive plan-- to make people feel safe and welcome contributing to Foundation projects, be that in code, writing, or community.

[RoboPetr]

Very good!

[RoboPetr]

Very good!

[AntouanK]

Great news. Well done.

[AntouanK]

Great news. Well done.

[steelbrain]

❤️

[steelbrain]

❤️

[hughrawlinson]

👍

[hughrawlinson]

👍

[MrBuddyCasino]

And all it took was for Microsoft to fork it. Embrace, extend... profit?

[MrBuddyCasino]

And all it took was for Microsoft to fork it. Embrace, extend... profit?

[Fauntleroy]

[Fauntleroy]

[tliber]

👍

[tliber]

👍

[u0m3]

👍
Is there an ETA for first merged release?

[u0m3]

👍
Is there an ETA for first merged release?

[yograterol]

[yograterol]

[kukicado]

👍👍👍👍👍

[kukicado]

👍👍👍👍👍

[sindresorhus]

[sindresorhus]

[xdartxvictor]

[xdartxvictor]

[ionmx]

👍

[ionmx]

👍

[lemonizer]

🎉

[lemonizer]

🎉

[adamsrog]

Huzzah! 👍

[adamsrog]

Huzzah! 👍

[GastonRosso]

Nice, thank you!

[GastonRosso]

Nice, thank you!

[pomke]

This is horrible 👎 ..

ok I just wanted to be contrary, woohoo ! 👍

[pomke]

This is horrible 👎 ..

ok I just wanted to be contrary, woohoo ! 👍

[samuba]

[samuba]

[saru95]

Great (y) !

[saru95]

Great (y) !

[selfrefactor]

So it is official: Node.js will rule as this big obstacle is over.

[selfrefactor]

So it is official: Node.js will rule as this big obstacle is over.

[ghost]

6 months before it is on the same pathetic state things were before the fork. You heard here first.

[ghost]

6 months before it is on the same pathetic state things were before the fork. You heard here first.

[APTy]

😎 👍 fantastic

[APTy]

😎 👍 fantastic

[christianbundy]

👍

[christianbundy]

👍

[Qard]

@mrseth Not going to happen. The community has control now.

[Qard]

@mrseth Not going to happen. The community has control now.

[filipedeschamps]

Congratulations guys!!!

[filipedeschamps]

Congratulations guys!!!

[andrewdeandrade]

What's the expected timeframe on the codebase convergence and getting to 3.0?

I see @Fishrock123's pull request. Is there a todo list of what remains after that is merged in?

Lastly, what's the deal with migrating existing open issues from node.js/io.js to the new repo?

[andrewdeandrade]

What's the expected timeframe on the codebase convergence and getting to 3.0?

I see @Fishrock123's pull request. Is there a todo list of what remains after that is merged in?

Lastly, what's the deal with migrating existing open issues from node.js/io.js to the new repo?

[nickleefly]

👍

[nickleefly]

👍

[carloscheddar]

[carloscheddar]

[TooBug]

Thanks for all your efforts!

[TooBug]

Thanks for all your efforts!

[ericmdantas]

Great job, everyone!

[ericmdantas]

Great job, everyone!

[karlbright]

Oh no! This means that the logo thread will come to an end!

[karlbright]

Oh no! This means that the logo thread will come to an end!

[Waterloo]

This is going to be awesome guys...

[Waterloo]

This is going to be awesome guys...

[izolate]

Started to prefer the name io.js. In my mind, we should have just continued down this forked road.

[izolate]

Started to prefer the name io.js. In my mind, we should have just continued down this forked road.

[Fishrock123]

Thanks all. I'm going to limit this discussion to collaborators, but anyone is free to either email me (fishrock123@rocketmail.com) if they have a comment they'd really like to have here, or comment in irc or some other place.

Basically all issues that could be brought up have been brought up, and I'm sure you'd be able to either find them by searching, or ask a collaborator / tc member. :)

[Fishrock123]

Thanks all. I'm going to limit this discussion to collaborators, but anyone is free to either email me (fishrock123@rocketmail.com) if they have a comment they'd really like to have here, or comment in irc or some other place.

Basically all issues that could be brought up have been brought up, and I'm sure you'd be able to either find them by searching, or ask a collaborator / tc member. :)

[Fishrock123]

6 months before it is on the same pathetic state things were before the fork.

As said, the new master will continue as things have in io.js

Oh no! This means that the logo thread will come to an end!

Ah, sadly yes. But we can always make a new thread for community node / io.js logos. Maybe we'll be able to open the node logo up to wider community interpretation and use. :)

Started to prefer the name io.js.

Ah same (naturally, I did come up with it), but it will still live on as having a huge impact on node. :)

[Fishrock123]

6 months before it is on the same pathetic state things were before the fork.

As said, the new master will continue as things have in io.js

Oh no! This means that the logo thread will come to an end!

Ah, sadly yes. But we can always make a new thread for community node / io.js logos. Maybe we'll be able to open the node logo up to wider community interpretation and use. :)

Started to prefer the name io.js.

Ah same (naturally, I did come up with it), but it will still live on as having a huge impact on node. :)

[Fishrock123]

@petergombos asked by email regarding #1664 (comment):

What's the expected timeframe on the codebase convergence and getting to 3.0?

It could either be either be shorter or longer (weeks, maybe 1-2 months?), depending on what happens with the finer details. The current working copy of the merge can be found at https://github.com/jasnell/node.js-convergence, it’s pretty nitty-gritty though, and the work is still getting warmed up so there’s not too much to see yet.

Also, the websites need to merge so that a new node website can form with the same internationalization abilities as iojs.org currently has. Progress for this can currently be tracked at nodejs/iojs.org#350, this may also include an updated node branding in the future.

So again, weeks, maybe a month or two. The current node.js and io.js release lines will continue releasing while we work on this.

I see @Fishrock123's pull request. Is there a todo list of what remains after that is merged in?

Assuming you mean nodejs/node-convergence-archive#7 ? Lots. These are only to update that repo to iojs/master. Still need to pull in the changes from node.

Lastly, what's the deal with migrating existing open issues from node.js/io.js to the new repo?

They will remain as is and we will continue to reference them as-is. io.js issue will remain relevant for sure, and I'll keep a tab on them as best as I can. :)

---

Again, anyone is free to email me (fishrock123@rocketmail.com), and I'll be happy to answer questions / respond to comments. :)

[Fishrock123]

@petergombos asked by email regarding #1664 (comment):

What's the expected timeframe on the codebase convergence and getting to 3.0?

It could either be either be shorter or longer (weeks, maybe 1-2 months?), depending on what happens with the finer details. The current working copy of the merge can be found at https://github.com/jasnell/node.js-convergence, it’s pretty nitty-gritty though, and the work is still getting warmed up so there’s not too much to see yet.

Also, the websites need to merge so that a new node website can form with the same internationalization abilities as iojs.org currently has. Progress for this can currently be tracked at nodejs/iojs.org#350, this may also include an updated node branding in the future.

So again, weeks, maybe a month or two. The current node.js and io.js release lines will continue releasing while we work on this.

I see @Fishrock123's pull request. Is there a todo list of what remains after that is merged in?

Assuming you mean nodejs/node-convergence-archive#7 ? Lots. These are only to update that repo to iojs/master. Still need to pull in the changes from node.

Lastly, what's the deal with migrating existing open issues from node.js/io.js to the new repo?

They will remain as is and we will continue to reference them as-is. io.js issue will remain relevant for sure, and I'll keep a tab on them as best as I can. :)

---

Again, anyone is free to email me (fishrock123@rocketmail.com), and I'll be happy to answer questions / respond to comments. :)

[jasnell]

We're still compiling the actual todo list on the actual merges. It's a fairly nontrivial task.

Regarding the issues tracker, the existing issues db's in joyent/node and iojs/io.js will remain as they are, with a new starting-from-scratch issue db in the converged repo. It'll require a bit of coordination but having a new issue tracker was decided to be the least painful option.

[jasnell]

We're still compiling the actual todo list on the actual merges. It's a fairly nontrivial task.

Regarding the issues tracker, the existing issues db's in joyent/node and iojs/io.js will remain as they are, with a new starting-from-scratch issue db in the converged repo. It'll require a bit of coordination but having a new issue tracker was decided to be the least painful option.