doc: initial convergence plan #66

jasnell · 2015-04-29T17:42:41Z

this is an initial draft. there are still plenty of details to fill in

jasnell · 2015-04-29T17:47:29Z

Fishrock123 · 2015-04-29T17:54:58Z

convergence.md

+
+The github.com/iojs organization was established to support the io.js project.
+
+The organization currently contains 112 members. (https://github.com/orgs/iojs/people)


You may not be able to see this, but it actually contains at least 281 members.

Figured as much. Not being a member of the organization gives me a limited view. For instance, I cannot see any of the existing teams that may have been formed. Perhaps I could be added to the organization?

I've invited you to the org, you should be able to see everything now.

mikeal · 2015-04-29T19:44:25Z

Couple comments:

The io.js is larger than that number, that number is only the people who have hit the "make public" next to their membership. The real numbers is currently 281.
There are a couple more org owners that just the TC that were added to help with some of the repository administration, I can't remember all of them offhand but I know @kosamari is on there to help setup i18n communities.
"Once transferred, the joyent/node repository will be renamed to nodejs-foundation/joyent-node" is this necessary? I'm a little worried about what happens to links to joyent/node after a double name change. Also, the node core team would have to deal with changing over the build system for no good reason. It's probably easier to continue node.js releases on joyent/node up until the new repository is setup and releasing. then we should probably move it over. In fact, we might just want to name the new repo "node.js" so that when joyent/node moves over it can maintain it's original name.
"Website and Social Media" should include Google Plus and Facebook. We should start a new thread in evangelism to catalog them.

jasnell · 2015-04-29T19:48:20Z

Renaming is not necessary, especially if we create the new repo as nodejs-foundation/node.js. Github's infrastructure does handle automatic redirections on renames but minimizing that would definitely be ideal. From what I understand, the redirections are handled properly on the git cli as well so I'm not sure how much of the existing build system would be affected. That'll be something we need to test.

Based on feedback...

domenic · 2015-04-29T20:18:15Z

convergence.md

+
+While the repositories are being merged, the existing io.js and node release streams will continue to operate. This implies that there will be new commits to both that will also need to be merged into the converged repo. Those are to be handled in generally the same way as the other commits.
+
+However, once the Foundation launches, the decision making process for both release streams follows the Foundation TSC guidelines with the combined TSC overseeing both individual release lines. Decisions about features / fixes going into the separate node.js and io.js lines will be the responsibility of the *combined* TSC. This helps to ensure that the decisions for what items make it into the converged project are being properly reviewed following the Foundation process.


This doesn't seem reasonable. Until an actual converged release happens, we have no proof that the new process works, and so we shouldn't shut down the old processes.

The "new" process is essentially a slightly revised version of the existing io.js process. The main point here is that the TCs are brought together and that decisions are made with convergence in mind. We don't want new conflicting things going independently into each release line which ends up just causing us more pain later.

Plus, the ability to evolve the process is built into the process so if things don't work as well as they should, we iterate and improve them as opposed to abandoning back to the "old" process.

mikeal · 2015-04-29T20:18:19Z

we should also note that the core collaborators from io.js and node.js will also merge and have write access on the new repo.

mikeal · 2015-04-29T20:29:35Z

However, once the Foundation launches, the decision making process for both release streams follows the Foundation TSC guidelines with the combined TSC overseeing both individual release lines.

I'd advise against this. We're going to have a lot of extra work in this interim phase where the projects are converging and we're still doing node.js and io.js releases on the old lines.

What probably works best is to let both projects continue using their existing process rather than ramping up both teams on the state of the old lines and putting that through the new process along with all the new work landing in the combined repo.

It may be worth re-iterating that once the first release of the merged project is complete all LTS releases from both old projects falls under the new structure for LTS.

jasnell · 2015-04-29T20:33:37Z

The specific individual day to day details for each release line can be handled by the existing TC's for each project. The key concern (as I mentioned in response to @domenic ) is when features or fixes go in to one release line that conflict with what's going into another. We do not want to get into a situation where the release lines diverge further after foundation launches while we are trying to bring the lines together. When new things are being proposed or when significant fixes come in that can have an impact on the larger effort, those should be reviewed by the combined TC.

mikeal · 2015-04-29T20:35:19Z

@jasnell i see, makes sense.

jasnell · 2015-04-29T21:05:39Z

I've revised the language a bit on that part. Hopefully for the better.

misterdjules · 2015-04-29T21:48:37Z

convergence.md

+* http://github.com/joyent/node-advisory-board
+* http://github.com/joyent/http-parser
+* http://github.com/joyent/node-tracing ?
+* http://github.com/joyent/docker-node ?


What is the meaning of "?" here? If it's "should this belong to the Node.js foundation once it's created?", I would say yes for docker-node. node-tracing seems like an experiment in coming up with some tracing tools based on async listener, I'm not sure it should move over.

The ? is that I am not yet sure if those should move or not. Looking for
input.

On Wed, Apr 29, 2015 at 2:48 PM, Julien Gilli [email protected]
wrote:

In convergence.md
#66 (comment):

+* http://github.com/trevnorris
+* http://github.com/indutny
+* http://github.com/mhdawson
+* http://github.com/jasnell
+* http://github.com/srl295
+
+#### Repositories
+
+Node and several of it's dependencies / related projects currently reside within the http://github.com/joyent organization.
+
+* http://github.com/joyent/node
+* http://github.com/joyent/node-website
+* http://github.com/joyent/node-advisory-board
+* http://github.com/joyent/http-parser
+* http://github.com/joyent/node-tracing ?
+* http://github.com/joyent/docker-node ?

What is the meaning of "?" here? If it's "should this belong to the
Node.js foundation once it's created?", I would say yes for docker-node.
node-tracing seems like an experiment in coming up with some tracing tools
based on async listener, I'm not sure it should move over.

—
Reply to this email directly or view it on GitHub
https://github.com/jasnell/dev-policy/pull/66/files#r29384828.

Re: docker-node

Yeah, it probably should moved over to the foundation.

monsanto · 2015-04-30T09:53:29Z

It would be ideal if one of the two existing GitHub repos was renamed to be the final repo, to preserve the star count of the project. Preferably joyent/node.

All things considered this is a very minor point, but node.js fights for mindshare with other platforms such as Go, and the absurdly high star count of joyent/node gives legitimacy and helps w/ visibility.

Just a thought.

orangemocha · 2015-04-30T12:11:55Z

convergence.md

+
+### Merge Process
+
+Of the two existing repositories, `iojs/io.js` has been the most active since the fork. Since that time, there has been some cherry-picking of commits between the two projects but the activity has been inconsistent and the separate code bases have diverged in fairly significant ways. Based on the commit history, the easiest merge approach will be to create the new `nodejs-foundation/node` repository as a Fork of the existing `iojs/io.js` (`nodejs-foundation/io.js`) repository, then cherry pick commits from `joyent/node` (`nodejs-foundation/node`) to merge in. Unfortunately, this will not be as easy as simply using `git format-patch` and `git am`.


the new nodejs-foundation/node repository

Did you mean nodejs-foundation/node**.js** ?

Yes, will fix in the next commit. Thanks!

Fishrock123 · 2015-04-30T13:31:09Z

It would be ideal if one of the two existing GitHub repos was renamed to be the final repo, to preserve the star count of the project. Preferably joyent/node.

I'd prefer the trade-off of not having to deal with that issue tracker, personally.

All things considered this is a very minor point, but node.js fights for mindshare with other platforms such as Go, and the absurdly high star count of joyent/node gives legitimacy and helps w/ visibility.

Does it? io.js got 11k+ (1/3 of joyent/node's) stars in like 2 months.

monsanto · 2015-04-30T13:43:14Z

Dealing with the issue tracker

Just close all of the open issues. Same result as creating a new repo and abandoning the old repos.

Does it? io.js got 11k+ (1/3 of joyent/node's) stars in like 2 months.

Pretty sure it has tapered off since. The same thing will happen with a new repo: you make an announcement, the community active at that time will star it (maybe bringing it to ~11k like now?), and then it will slowly gain stars like any other mature project. Using joyent/node gives us a head start. It's an old repo by GitHub standards, so there are many people who have starred that repo who have left the JavaScript world or will otherwise never check that GitHub page again.

This is such a petty thing, but since I don't think there are many downsides to just reusing joyent/node, I felt I needed to propose it.

jasnell · 2015-04-30T14:56:23Z

While the star count is useful, I personally don't see it as critical. Given that the two release lines will continue in parallel for at least some period of time (hopefully a short period of time), and given that there are still LTS concerns for both lines, creating a separate repo with a separate issues repo just seems to be the cleanest approach.

domenic · 2015-04-30T15:11:15Z

convergence.md

+4. All members of the existing node-coreteam will be added as Collaborators within the organization
+5. A team representing the TSC members will be created (if one does not already exist). The membership of this team will be all current voting members of both the node-coreteam and io.js TC.
+6. Ownership of the following joyent/* repositories will be transferred to the Node.js Foundation organization:
+  * http://github.com/joyent/node


Can we rename it to nodejs-foundation/joyent-node or something? Having nodejs-foundation/node and nodejs-foundation/node.js seems horrible.

I originally had it as joyent-node but there was some push back. This is an open discussion point tho. Whichever causes the least amount of disruption should be the preferred approach.

doc: initial convergence plan

jasnell · 2015-04-30T21:24:42Z

Landed

doc: initial convergence plan

e5b29d0

this is an initial draft. there are still plenty of details to fill in

jasnell mentioned this pull request Apr 29, 2015

Proposed Foundation Convergence Plan nodejs/node-v0.x-archive#25088

Closed

Fishrock123 reviewed Apr 29, 2015
View reviewed changes

doc: refinements and corrections

4aea045

Based on feedback...

domenic reviewed Apr 29, 2015
View reviewed changes

doc: refinement on parallel release line changes

40fb7a9

misterdjules reviewed Apr 29, 2015
View reviewed changes

orangemocha reviewed Apr 30, 2015
View reviewed changes

domenic reviewed Apr 30, 2015
View reviewed changes

jasnell added 2 commits April 30, 2015 10:23

doc: CI infrastructure detail + other minor tweaks

6601ca1

doc: link to the branches and tags

7f17075

jasnell added a commit that referenced this pull request Apr 30, 2015

Merge pull request #66 from jasnell/initial-convergence

5833dfb

doc: initial convergence plan

jasnell merged commit 5833dfb into master Apr 30, 2015

jasnell mentioned this pull request Apr 30, 2015

Minutes from 2015-04-30 Call #68

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

doc: initial convergence plan #66

doc: initial convergence plan #66

jasnell commented Apr 29, 2015

jasnell commented Apr 29, 2015

Fishrock123 Apr 29, 2015

jasnell Apr 29, 2015

Fishrock123 Apr 29, 2015

mikeal Apr 29, 2015

mikeal commented Apr 29, 2015

jasnell commented Apr 29, 2015

domenic Apr 29, 2015

jasnell Apr 29, 2015

mikeal commented Apr 29, 2015

mikeal commented Apr 29, 2015

jasnell commented Apr 29, 2015

mikeal commented Apr 29, 2015

jasnell commented Apr 29, 2015

misterdjules Apr 29, 2015

jasnell Apr 29, 2015

chorrell Apr 30, 2015

monsanto commented Apr 30, 2015

orangemocha Apr 30, 2015

jasnell Apr 30, 2015

Fishrock123 commented Apr 30, 2015

monsanto commented Apr 30, 2015

jasnell commented Apr 30, 2015

domenic Apr 30, 2015

jasnell Apr 30, 2015

jasnell commented Apr 30, 2015


		The github.com/iojs organization was established to support the io.js project.

		The organization currently contains 112 members. (https://github.com/orgs/iojs/people)


		While the repositories are being merged, the existing io.js and node release streams will continue to operate. This implies that there will be new commits to both that will also need to be merged into the converged repo. Those are to be handled in generally the same way as the other commits.

		However, once the Foundation launches, the decision making process for both release streams follows the Foundation TSC guidelines with the combined TSC overseeing both individual release lines. Decisions about features / fixes going into the separate node.js and io.js lines will be the responsibility of the combined TSC. This helps to ensure that the decisions for what items make it into the converged project are being properly reviewed following the Foundation process.


		### Merge Process

		Of the two existing repositories, `iojs/io.js` has been the most active since the fork. Since that time, there has been some cherry-picking of commits between the two projects but the activity has been inconsistent and the separate code bases have diverged in fairly significant ways. Based on the commit history, the easiest merge approach will be to create the new `nodejs-foundation/node` repository as a Fork of the existing `iojs/io.js` (`nodejs-foundation/io.js`) repository, then cherry pick commits from `joyent/node` (`nodejs-foundation/node`) to merge in. Unfortunately, this will not be as easy as simply using `git format-patch` and `git am`.

doc: initial convergence plan #66

doc: initial convergence plan #66

Conversation

jasnell commented Apr 29, 2015

jasnell commented Apr 29, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikeal commented Apr 29, 2015

jasnell commented Apr 29, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikeal commented Apr 29, 2015

mikeal commented Apr 29, 2015

jasnell commented Apr 29, 2015

mikeal commented Apr 29, 2015

jasnell commented Apr 29, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

monsanto commented Apr 30, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Fishrock123 commented Apr 30, 2015

monsanto commented Apr 30, 2015

jasnell commented Apr 30, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jasnell commented Apr 30, 2015