Changes between Version 1 and Version 2 of GitHubandNewProcesses


Ignore:
Timestamp:
Sep 27, 2021 4:42:59 PM (4 weeks ago)
Author:
Jon Davis
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GitHubandNewProcesses

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