Changes between Version 1 and Version 2 of GitHubandNewProcesses

Timestamp:

Sep 27, 2021 4:42:59 PM (3 years ago)

Author:

Jon Davis

Comment:

--

GitHubandNewProcesses

@@ -1 +1 @@
 == GitHub and New Processes ==
 ''by Jonathan Bedard''
+
+Jonathan: talking bout contribution workflows and what is planned and what is already implemented
+
+Jonathan: we've talked a lot about identifiers and many of our services have already started using them
+
+Jonathan: talking bout configuration settings for setting up access to the git repo
+
+Jonathan: command lines tools talk to GitHub with personal git access tokens
+
+the git-webkit setup scripts takes the token and saves it
+
+we also will be creating personal forks so that we don't pollute git webkit repo with personal development branches
+
+you will have multiple remotes: your origin, your fork, and other users forks if you are reviewing their code and want to download it
+
+we will be creating tooling to help with that
+
+when you get to making code change, like webkit patch, we will help automate
+
+git-webkit will take all your local changes, create a branch prefixed by eng/, open a git editor, populate the commit message
+
+we will be removing changelings when we move to git, they break merging workflows
+
+git-webkit will also do a set of pre commit checks, and display a final diff check, and then create pull request
+
+then slides were all pulled from a pull request last week and you can go check it out on our webkit repo on github
+
+ews is going to integrate with GitHub checks
+
+last thing to talk about is commit-queue
+
+our goals for cq are that we leverage GitHub  ui, leverage branch permissions, offload complexity onto automation, support pre-push hooks
+
+check that you are a committer and the reviewer was a reviewer etc.
+
+we want rebase and merge button to work
+
+normally what the button does will rebase pull-request onto main, merge, and update the main ref
+
+but it doesn't allow us to run any tests
+
+we;re going to have a cq-main branch
+
+when you generate you're pull-request it will be against the cq branch
+
+it allow us to protect main
+
+bots will then cherry-pick from cq-main onto main
+
+its going to test and then merge onto main
+
+there is complexity, but we think the complexity is handled by the cq not the engineers
+
+yes, there are some race conditions, but that is part of git and we think the bots will be able to handle it with retry
+
+delayed tree, what happens if someone has a pull request coming from that delayed tree
+
+the delayed tree is the same as the protected tree, so the way the rebase and merge tree will work for pull requests
+
+is that there are two cq branches, one from both trees,
+
+the delayed branch will cherry-pick to cq main, if that works we're good
+
+if that doesn't then they will need to get accessor, or wait - we expect that to not be very common
+
+=== Q & A Discussion ===
+
+maciej: 1 how will the tierataction between the protected tree and personal forks work? will our personAL Tree be protected
+
+Jonathan: believes the tooling will support this, a faked repo by default has the same protection as the upstream branch.  He needs to check
+
+Sam: you won't even be able to make it public
+
+Jonatahn: delayed tree won't be a fork according to github
+
+maciej: so there isn't an easy way to make your personal fork public?
+
+that a downside than if your branches lived in the main tree
+
+having dev branches be secret forever is a weird side effect of the protected tree
+
+Jonathan: current safari tree has a lot of stale branches which is the downside to having dev branches in the main tree
+
+maciej: as a GitHub newbie, is scared of having multiple upstream but hopefully the tooling hides all that
+
+maciej: speaking of wrappers
+
+webkit-patch is svn designed but it would be good to make the sub commands work with git, to keep the workflow seems like an advantage than migrating to a different tool with different commands
+
+Jonathan: webkit-patch does a lot more than most people realize, it is possible to migrate some commands with obvious parallels.
+
+maciej: ok to deprecate obscure functionality seems unnecessary to change command line interface
+
+maciej: favorite thing is the thing that makes the bug and pull request all at once
+
+one other thing the term pfr is weird, but its a pull request not a patch, that term could be confusing
+
+I do hope that most of the tools that do stuff should have minimal output
+
+git tends to be spammy
+
+Myles; our developers that are committers going to be prohibited from landing manually
+
+Jonathan: we are going to be moving to a cq only world
+
+if we don't there is no way to enforce anything on main
+
+we are creating a fast cq
+
+the only thing that branch will do will be the minimal checks so you can land without waiting too long
+
+Jonathan: in this world being a committer means you have access to the cq branch
+
+maciej: one thought, the fast path should have a scary name and be obscure
+
+cq its semantics are meant to be a queue, but its a stack, that has a lot of rebasing. will landing onto the commit queue squash or rebase
+
+Jonathan: rebase, this isn't any worse than how cq already works
+
+maciej: what happens if fast path cq introduces a conflict, is cq now broken
+
+maciej: can things from the cq land out of order?
+
+Jonathan: yes
+
+Jonathan: it sounds scary but these are problems the current cq already has
+
+maciej: because new cq is a branch and not just a patch it might have additional failure points
+
+Jonathan it is possible
+
+Alexey: needs to rethought because we are going to need more than on cq.
+
+one cq
+
+Jonathan: the design im thinking about has a lot of cherry picking but should allow for more than one cq bot
+
+maciej: this adds a lot of complexity we should be sure the big green button is worth it
+
+Mickhail: are we rewriting history?
+
+Jonathan cq patches will be constantly rewritten
+
+when we grab delayed patch if will be removed and moved to protected cq.  if it fails cq it will go back to the pull request say you failed and reopen it
+
+Keith: is their a plan in place when we start switching over to go back if there are problems?
+
+Jonathan: when GitHub is the source of truth switching back will be difficult.  during the transition we will bring up the cq on GitHub.  and that could be switched from GitHub push to main vs. git svn commit easily
+
+if we really founds ourselves in a spot of trouble we could dcommit each patch as we go through
+
+svn won't handle all git patches
+
+Keith: we should do both in parallel for a couple months