Changes between Version 1 and Version 2 of GitHubandNewProcesses

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



  • GitHubandNewProcesses

    v1 v2  
    11== GitHub and New Processes ==
    22''by Jonathan Bedard''
     4Jonathan: talking bout contribution workflows and what is planned and what is already implemented
     6Jonathan: we've talked a lot about identifiers and many of our services have already started using them
     8Jonathan: talking bout configuration settings for setting up access to the git repo
     10Jonathan: command lines tools talk to GitHub with personal git access tokens
     12the git-webkit setup scripts takes the token and saves it
     14we also will be creating personal forks so that we don't pollute git webkit repo with personal development branches
     16you will have multiple remotes: your origin, your fork, and other users forks if you are reviewing their code and want to download it
     18we will be creating tooling to help with that
     20when you get to making code change, like webkit patch, we will help automate
     22git-webkit will take all your local changes, create a branch prefixed by eng/, open a git editor, populate the commit message
     24we will be removing changelings when we move to git, they break merging workflows
     26git-webkit will also do a set of pre commit checks, and display a final diff check, and then create pull request
     28then slides were all pulled from a pull request last week and you can go check it out on our webkit repo on github
     30ews is going to integrate with GitHub checks
     32last thing to talk about is commit-queue
     34our goals for cq are that we leverage GitHub  ui, leverage branch permissions, offload complexity onto automation, support pre-push hooks
     36check that you are a committer and the reviewer was a reviewer etc.
     38we want rebase and merge button to work
     40normally what the button does will rebase pull-request onto main, merge, and update the main ref
     42but it doesn't allow us to run any tests
     44we;re going to have a cq-main branch
     46when you generate you're pull-request it will be against the cq branch
     48it allow us to protect main
     50bots will then cherry-pick from cq-main onto main
     52its going to test and then merge onto main
     54there is complexity, but we think the complexity is handled by the cq not the engineers
     56yes, there are some race conditions, but that is part of git and we think the bots will be able to handle it with retry
     58delayed tree, what happens if someone has a pull request coming from that delayed tree
     60the delayed tree is the same as the protected tree, so the way the rebase and merge tree will work for pull requests
     62is that there are two cq branches, one from both trees,
     64the delayed branch will cherry-pick to cq main, if that works we're good
     66if that doesn't then they will need to get accessor, or wait - we expect that to not be very common
     68=== Q & A Discussion ===
     70maciej: 1 how will the tierataction between the protected tree and personal forks work? will our personAL Tree be protected
     72Jonathan: believes the tooling will support this, a faked repo by default has the same protection as the upstream branch.  He needs to check
     74Sam: you won't even be able to make it public
     76Jonatahn: delayed tree won't be a fork according to github
     78maciej: so there isn't an easy way to make your personal fork public?
     80that a downside than if your branches lived in the main tree
     82having dev branches be secret forever is a weird side effect of the protected tree
     84Jonathan: current safari tree has a lot of stale branches which is the downside to having dev branches in the main tree
     86maciej: as a GitHub newbie, is scared of having multiple upstream but hopefully the tooling hides all that
     88maciej: speaking of wrappers
     90webkit-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
     92Jonathan: webkit-patch does a lot more than most people realize, it is possible to migrate some commands with obvious parallels.
     94maciej: ok to deprecate obscure functionality seems unnecessary to change command line interface
     96maciej: favorite thing is the thing that makes the bug and pull request all at once
     98one other thing the term pfr is weird, but its a pull request not a patch, that term could be confusing
     100I do hope that most of the tools that do stuff should have minimal output
     102git tends to be spammy
     104Myles; our developers that are committers going to be prohibited from landing manually
     106Jonathan: we are going to be moving to a cq only world
     108if we don't there is no way to enforce anything on main
     110we are creating a fast cq
     112the only thing that branch will do will be the minimal checks so you can land without waiting too long
     114Jonathan: in this world being a committer means you have access to the cq branch
     116maciej: one thought, the fast path should have a scary name and be obscure
     118cq 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
     120Jonathan: rebase, this isn't any worse than how cq already works
     122maciej: what happens if fast path cq introduces a conflict, is cq now broken
     124maciej: can things from the cq land out of order?
     126Jonathan: yes
     128Jonathan: it sounds scary but these are problems the current cq already has
     130maciej: because new cq is a branch and not just a patch it might have additional failure points
     132Jonathan it is possible
     134Alexey: needs to rethought because we are going to need more than on cq.
     136one cq
     138Jonathan: the design im thinking about has a lot of cherry picking but should allow for more than one cq bot
     140maciej: this adds a lot of complexity we should be sure the big green button is worth it
     142Mickhail: are we rewriting history?
     144Jonathan cq patches will be constantly rewritten
     146when 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
     148Keith: is their a plan in place when we start switching over to go back if there are problems?
     150Jonathan: 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
     152if we really founds ourselves in a spot of trouble we could dcommit each patch as we go through
     154svn won't handle all git patches
     156Keith: we should do both in parallel for a couple months