Moving repos / convergence #2327
Comments
Right, we have a unified workflow for testing pull requests but two different workflows for landing pull requests between v0.12/v0.10 and io.js. The work to bring the landining-via-jenkins to io.js & converged repo is very close to completion. However, it doesn't need to block us from moving to the converged repo. Both the testing and the landing pr jobs take the repo as a parameter. We should ensure that the node-release job that is currently used for v0.x releases is not hardcoded to use joyent/node. If it is, it should trivial to fix that. |
|
+1 for renaming nodejs/io.js to nodejs/node. The pull requests at https://github.com/nodejs/node/pulls will need to be re-applied, and note that a few have already landed. It looks like the commits that should be ported from joyent/node have been listed in issues but the work to cherry-pick, solve merge conflicts and pass tests hasn't been done yet. That's gonna take some time. Perhaps it will be good to do it in a separate branch so that multiple people can work on it while we stabilize it. Of course we should rename nodejs/node to something else (e.g. converged-node-temp) before renaming nodejs/io.js to nodejs/node. |
It does now: https://developer.github.com/changes/2015-07-21-automatic-redirects-for-renamed-repositories/ |
mscdex
added
the
meta
|
These are the only two commits (by name and PR-URL) on nodejs/node that aren't on io.js master:
|
I'd move it over, otherwise people will keep filing issues against it. |
|
@bnoordhuis You mean move the commits and rename the iojs repo to node? |
|
Sorry, I mean move joyent/node to nodejs/node-legacy. And yes, rename nodejs/io.js to nodejs/node. Maybe replace the contents of nodejs/node-legacy with a README pointing people to nodejs/node and close the issue tracker (maybe - not sure if that's a good idea.) It won't block people from filing pull requests against the old repo, you can't disable those on GH, but that's probably less noise than the issue tracker. |
|
Hmmm I think I'll miss the io.js name :( |
|
+1!! |
|
Seems to make sense.
|
|
+1 It's good to know that current nodejs/io.js issues and pull requests would not be lost or forgotten. |
|
@Fishrock123 mentioned that some things (issues?) link to issues in the current converged repo. We might want to edit them after the fact. |
|
Some of the |
Just need to make sure the related PRs and Commits have updated cross-links. I'll try to take care of this today-ish. |
|
+1. On this. As soon as we can get this consolidated, the better. I'm neutral on bringing |
|
Can we already rename nodejs/node to something else but wait just a bit to move io.js overtop of it? It'l make it easier to update any links then and there rather than trying to make a list. |
Just so that we have a nice TODO list, what is holding up moving the io.js repo to node other than there being a repo there already? |
Finding anything important that linked to the current nodejs/node repo. But since no-one seems to think anything is and I haven't been able to look much yet, go right ahead I guess. |
I'm going to guess that this might break some of the build stuff we have setup??? @nodejs/build |
Most likely the job that trigger nightly builds might have to be updated to build the new repo, if that's not handled automatically by the redirect. One more thing to check: if git access nodejs/io.js is setup to redirect to nodejs/node, and if nodejs/node is setup to redirect to nodejs/converged-repo-archive, will this cause a redirect of nodejs/io.js to nodejs/converged-repo-archive? Not sure how these redirect are setup, if explicitly or implicitly when renaming, but it would be easy to test that with some temp repos. |
|
|
Just tested the way GitHub handles the two redirects and it's not going to break us. I created two temp repos to simulate what we are trying to do. Based on this test, I expect that after renaming nodejs/node to nodejs/node-convergence-archive and nodejs/io.js to nodejs/node:
... as explained by this warning on the GitHub help page: |
|
Based on consensus here, I renamed nodejs/node to nodejs/node-convergence-archive: https://github.com/nodejs/node-convergence-archive |
|
@rvagg and @nodejs/build , does anything need to be changed in the nightly build configs to point to nodejs/node? Once that's cleared, I think we can go ahead with renaming io.js. |
|
@orangemocha 👍 — should the |
|
@srl295 : agreed. Now I have a plane to catch, so I will get to it after I resurface on the other side of the ocean... or feel free to make the change 👍 |
|
Updated repo descriptions for both |
|
Sounds like we have consensus on the important issues here, no need to push to tsc-agenda. The only outstanding one is the move of joyent/node but that's a non-blocker for everything else. I'm going to rename io.js to node right now and fix up the nightly build stuff for that. Hold onto your seats. |
|
Renamed, https://github.com/nodejs/io.js -> https://github.com/nodejs/node nightlies are now set to come off nodejs/node#v3.x and next-nightlies are set to come off nodejs/node#master |
|
iojs and node has been merged now! :) |
|
All Future will be from the nodejs/nodejs.README.md just has not been updated. |
|
Good news |
|
Nice to see convergence at last :) Bravo ! |
|
👍 |
|
Could someone update the default target repo for the CI to use nodejs/node instead of nodejs/io.js? |
done |
|
Q: what about the joyent/node wiki? Should it be merged in? I assume the content needs to be replaced with some combination of doc/website things? |
|
@srl295 Since nodejs/node will also be used to host the v0.10 and v0.12 branches, some of the content from joyent/node's Wiki will need to be merged. These are some of the Wiki pages that I want to keep after the merge process:
These pages have some overlap with existing documents in the nodejs/node Wiki, but we need to keep what is specific to the v0.10 and v0.12 branches. There might be other pages we want to keep. |
|
@misterdjules #440 (comment) notes that the wikis are a git repo (!), so could be merged via git. |
|
@nodejs/tsc @nodejs/build v0.10 and v0.12 branches from joyent/node need to be pushed to nodejs/node, and development on these branches need to happen in nodejs/node as soon as possible. joyent/node should also move to the nodejs org asap. |
|
+1. I am working to get the open PRs organized too as all of those are
|
|
We could stop accepting new PRs in joyent/node, but keep the existing ones and land them by porting the commits to the new repo. |
|
In the process of doing so now. New PRs should definitely only happen in
|
|
So what prevents us from pushing the v0.10 and v0.12 branches to nodejs/node and continue development there? |
|
Just caution... making sure nothing breaks :-) If you feel we're good to On Fri, Aug 14, 2015 at 10:46 AM, Alexis Campailla <notifications@github.com
|
|
@orangemocha @jasnell On joyent/node's side, as long as nothing is deleted/removed there, I don't see a risk of breaking anything. Moving joyent/node to the nodejs GitHub org might break a few things, but we can give a heads up to all dependents about that. |
|
Right @misterdjules , moving the repo should be harmless. Anything needs to change in the release process? Regarding pushing the branches, perhaps we should at least clearly document the procedure for landing those existing PRs. I think it would involve pushing a temp branch on the new repo, landing it with node-accept-commit, then finally pushing the updated branch back to the joyent\node repo. I can write something up next week, perhaps even automate some of it within the existing CI. |
|
@orangemocha Releases of v0.10.x and v0.12.x still need to be done from jenkins.nodejs.org because signing keys for binaries/installers are still on a Windows agent connected to that CI platform. There's also the setup of the Linux agent used to build Linux binaries that uses a compiler that is old enough to support older C++ runtimes that can be found on e.g CentOS 5.7. If we have enough bandwidth, it would be ideal to fix those issues and move the release jobs to nodesource's Jenkins platform (actually, I believe the issue with older C++ runtimes is already solved in a better way on jenkins-iojs.nodesource.com). If not, we can still use the jenkins.nodejs.org CI platform for a while. The release guide can be used as is even after moving the joyent/node repository. |
|
Please take a look at nodejs/node-v0.x-archive#25876 |
|
This is now more or less done. See #2522 for updated info about 4.x. We may still need to document the release cycle somewhere more. |
See nodejs/node#2327. - `github.com/iojs/io.js` to `github.com/nodejs/node` - `github.comnodejs/io.js` to `github.com/nodejs/node`
At this stage, the v3.x branch should be assumed to be the last release branch for io.js, what's on
masterwill become Node.js v4.x and beyond along with convergence work which is largely contained within pull requests to nodejs/node—there are some additional changes but they are already coming over to this repo as pull requests, such as #2302.With regard to releases & CI we have near-convergence but it's not complete:
So, how do we handle this? How do we deal with the multiple repositories and how do we get towards a Node.js v4 alpha ASAP?
Proposed plan
I propose that we do the following as soon as we get consensus, it can go on
tc-agendaif necessary.Rename nodejs/io.js to nodejs/node
I've had discussions with many people about the merits of renaming vs just jumping over to nodejs/node. One of the interesting benefits of not renaming is that it resets the expectations of the entire contributor base (tsc, collaborators and beyond) that this is a new thing we are doing, not just io.js.
However, the current nodejs/node doesn't contain much that we can't afford to lose even if we were to delete it. There are pull requests in there that bring us to the convergence but the codebase is just io.js. So we could easily bring those pull reuqests into this repo and rename it and we keep the history and existing issues and pull requests that are more relevant to the converged codebase than those in joyent/node.
Already, pull requests and issues that are not directly relevant to 0.10 and 0.12 are being prompted to file against io.js, that can continue but with people being pointed to nodejs/node.
Create all future releases from nodejs/node
Not only for v4 but also v3 and even 0.10 and 0.12. This means the release tooling just needs to work in one way with the only difference being that v3 releases go to iojs.org but that'll end soon enough. I'm suggesting we have
v0.10.xandv0.12.xbranches for this to match thev3.xbranch we now have.Leave joyent/node in place for now
It'd be great if it could be moved to nodejs/node-legacy or similar but there's no reason that this should be a priority and existing tooling that points to joyent/node—not just official stuff but community tooling too, and while the GitHub web interface redirects, the GitHub API doesn't.
We should encourage all new issues against joyent/node to be filed in nodejs/node instead. We should encourage people who filed the existing pull requests over there to file them against nodejs/node and then work (slowly) to close all of them out completely.
Document the branch strategy for casual contributors
While the core group of contributors might be starting to get their heads around the new model that we've been discussing, it's vitally important that we communicate a simplified version of this that we can put at the top of CONTRIBUTING.md and (?) the top of README.md. Something simple enough that people are likely to read it but informational enough that it tells people which branch any pull requests should go against. Something like:
Issues should state clearly which version of Node.js or io.js they are reporting against
Pull requests should be made against
masterexcept where they are addressing bugs in older versions where the bugs either don't exist inmasteror do exist inmasterbut the changes are significantly different and will therefore require a fresh pull request.Stable releases are made from their own branches, with changes in
masterbeing cherry-picked from there into those branches where appropriate. Generally it should be left for the collaborator team to decide whether changes should be cherry-picked at all and to which branches.The process for cherry-picking from
masterto stable branches will be interesting and we're going to learn best practices over time, I suspect that we'll see a lot of compounding pull requests where a cherry-pick isn't clean and requires some editing./cc @nodejs/tsc
The text was updated successfully, but these errors were encountered: