Open mmarchini opened 3 years ago
We can start by creating the main
branch with an empty README, and then slowly we can work on the other changes there (via PRs) and then once we're confident this new system is working and is better than the current state we can switch it.
Drop
canary-base
branch onnodejs/node
and use patch files on this repository instead.
I'm not opposed to it, but having a branch to manage the canary patches helps me a lot because I can easily use git cherry-pick
and git rebase
. We need to make sure patch files don't slow down the regular processes of
nodejs/node
Definitely. I'm proposing these changes because I do believe they will make the overall process faster (or at least simpler), but we'll definitely need some experimentation in order to get it right.
Edit: for major V8 upgrades, we could even have an Action that opens the PR and updates it every time we update the patches list (edit 2: and dropping canary-base
is not a requirement for that, so I'll go ahead and add it to the list :) )
Besides dropping the canary-base
branch, what are your thoughts on the other changes?
Other changes SGTM
main
branch in this repositorycanary
branch as we have todaycanary/
folder which is a copy ofnodejs/node
with patches appliedv8-canary
branch onnodejs/node
and have it as a submodule herecanary
branch for relevant jobscanary
branchnodejs/node
canary-base
branch onnodejs/node
and use patch files on this repository instead (need to experiment to ensure it doesn't worsen our workflow)