Skip to content
This repository has been archived by the owner on Apr 18, 2018. It is now read-only.

doc: initial convergence plan #66

Merged
merged 5 commits into from
Apr 30, 2015
Merged

doc: initial convergence plan #66

merged 5 commits into from
Apr 30, 2015

Conversation

jasnell
Copy link
Member

@jasnell jasnell commented Apr 29, 2015

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

/cc: @mikeal

this is an initial draft. there are still plenty of details to fill in
@jasnell
Copy link
Member Author

jasnell commented Apr 29, 2015

nodejs/node#1557


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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @mikeal

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@mikeal
Copy link

mikeal commented Apr 29, 2015

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
Copy link
Member Author

jasnell commented Apr 29, 2015

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...

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.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link

mikeal commented Apr 29, 2015

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
Copy link

mikeal commented Apr 29, 2015

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
Copy link
Member Author

jasnell commented Apr 29, 2015

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
Copy link

mikeal commented Apr 29, 2015

@jasnell i see, makes sense.

@jasnell
Copy link
Member Author

jasnell commented Apr 29, 2015

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

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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):

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re: docker-node

Yeah, it probably should moved over to the foundation.

@monsanto
Copy link

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.


### 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`.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the new nodejs-foundation/node repository

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, will fix in the next commit. Thanks!

@Fishrock123
Copy link
Contributor

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
Copy link

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
Copy link
Member Author

jasnell commented Apr 30, 2015

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.

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:
* https://github.com/joyent/node
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

jasnell added a commit that referenced this pull request Apr 30, 2015
@jasnell jasnell merged commit 5833dfb into master Apr 30, 2015
@jasnell
Copy link
Member Author

jasnell commented Apr 30, 2015

Landed

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants