Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restructure repository branches #170

Open
4 of 9 tasks
mmarchini opened this issue Sep 13, 2020 · 5 comments
Open
4 of 9 tasks

Restructure repository branches #170

mmarchini opened this issue Sep 13, 2020 · 5 comments

Comments

@mmarchini
Copy link

mmarchini commented Sep 13, 2020

  • Create main branch in this repository
    • Set it as default branch
  • Keep canary branch as we have today
    • Alternatively have a canary/ folder which is a copy of nodejs/node with patches applied
    • Alternatively 2 keep the V8 canary as a v8-canary branch on nodejs/node and have it as a submodule here
  • Ensure Jenkins fetches the canary branch for relevant jobs
  • Use GitHub Actions to update the canary branch
  • Use GitHub Actions to open the major V8 upgrade PR on nodejs/node
  • Drop canary-base branch on nodejs/node and use patch files on this repository instead (need to experiment to ensure it doesn't worsen our workflow)
@mmarchini
Copy link
Author

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.

@targos
Copy link
Member

targos commented Sep 13, 2020

Drop canary-base branch on nodejs/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

  • keeping gyp files up to date
  • preparing the V8 update PRs in nodejs/node

@mmarchini
Copy link
Author

mmarchini commented Sep 13, 2020

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

@mmarchini
Copy link
Author

Besides dropping the canary-base branch, what are your thoughts on the other changes?

@targos
Copy link
Member

targos commented Sep 13, 2020

Other changes SGTM

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

No branches or pull requests

2 participants