| | 1 | == Moving WebKit to Git == |
| | 2 | ''by Jonathan Bedard (Sony)'' [https://www.icloud.com/keynote/0J2GfqyXqASQQGdryxdWDWBrA#GitHubTransition Slide Deck] |
| | 3 | |
| | 4 | A short outline of the steps we’re taking and processes that will change in the next few months as we move WebKit off of Subversion and onto GitHub. |
| | 5 | |
| | 6 | ''Jonathan:'' This presentation will be about the timeline of moving WebKit to Git, along with the processes that come with it |
| | 7 | |
| | 8 | ''Jonathan:'' First, why are we going with GitHub instead of another solution (namely, self-hosted GitLab) |
| | 9 | |
| | 10 | ''Jonathan:'' GitHub is familiar for new contributors, familiar for web developers filing bugs, strong community developing supporting tools, 3rd party management of the repository (viewed as a plus by the maintainers) |
| | 11 | |
| | 12 | ''Jonathan:'' This explains why we are going with GitHub instead of a self-hosted solution |
| | 13 | |
| | 14 | ''Jonathan:'' Here is an overview of the timeline, it has changed since the last one that was shared because the git clone is taking longer than expected. |
| | 15 | |
| | 16 | ''Jonathan:'' Whenever large changes are made, we will be transparent about it ahead of time and will make sure that it is shared with our contributors |
| | 17 | |
| | 18 | ''Jonathan:'' Here are some processes that are going to be changing |
| | 19 | |
| | 20 | ''Jonathan:'''' Commit Identifiers:'' With svn revisions, we can know roughly where it is in time. We will be transitioning to commit identifiers, which reflect what branch the commit is on |
| | 21 | |
| | 22 | ''Jonathan:'' These identifiers are basically a translation layer for humans (since 12 character git hashes don’t mean much to humans), our tools will still work with git hashes |
| | 23 | |
| | 24 | ''Jonathan:'''' Protected branches:'' This is something done by other projects on GitHub, and we are going to do it too. |
| | 25 | |
| | 26 | ''Jonathan:'' Certain branches will receive additional protection, not everyone will be able to land changes. |
| | 27 | |
| | 28 | ''Jonathan:'' There will need to be a set of repository administrators that can modify the set of protected branches, should be roughly the same people that already have ssh access to the severs hosting the current repositories. |
| | 29 | |
| | 30 | ''Jonathan:'' Main (formerly known as master) will be protected |
| | 31 | |
| | 32 | ''Jonathan:'' Commit queue will be mandatory for commits to protected branches |
| | 33 | |
| | 34 | ''Jonathan:'' Since there are some changes that developers don’t want to wait for, we will add a “fast” mode to commit queue that respects “Unreviewed xxx fix” in lieu of a reviewer |
| | 35 | |
| | 36 | ''Jonathan:'' With that in mind, why have commit queue at all? |
| | 37 | |
| | 38 | ''Jonathan:'' We need it to handle some post-commit actions that are unsupported by GitHub |
| | 39 | |
| | 40 | ''Jonathan:'' Pull-requests will be squash merged initially |
| | 41 | |
| | 42 | ''Jonathan:'' This is because we believe EWS should act on each commit independently, we aren’t sure if we can handle that throughput at the moment. May change in the future. |
| | 43 | |
| | 44 | ''Jonathan:'' What is happening with patch workflows? |
| | 45 | |
| | 46 | ''Jonathan:'' We intend to replace patches with pull requests. However, the patch workflow will remain functional throughout the transition. |
| | 47 | |
| | 48 | ''Jonathan:'' Patch workflow may remain indefinitely for security bugs due to gits way of reasoning about branches. |
| | 49 | |
| | 50 | ''Jonathan:'' Trac doesn’t work with large git repositories, so we will be getting rid of it. |
| | 51 | |
| | 52 | ''Jonathan:'' Existing trac links will redirect to GitHub by way of a redirect service (since github will not natively respect commit identifiers) |
| | 53 | |
| | 54 | ''Jonathan:'' Bug Tracker will not be changed until the repository migration is complete, will be the last thing to change. |
| | 55 | |
| | 56 | ''Jonathan:'' Before we consider pushing developers away from bugzilla, we will need to support new incoming issues on GitHub. |
| | 57 | |
| | 58 | ''Jonathan:'' Bugzilla will remain for some use cases, namely security bugs |
| | 59 | |
| | 60 | ''Jonathan:'' More migration plans will be communicated in the Spring after we finish the migration |
| | 61 | |
| | 62 | ''Simon:'' Northern or Southern hemisphere spring? |
| | 63 | |
| | 64 | ''Jonathan:'' Northern hemisphere, March/April |
| | 65 | |
| | 66 | ''Ryosuke:'' If i look at the blame on GitHub there will be no identifier, how can I identify it? |
| | 67 | |
| | 68 | ''Jonathan:'' That is why we want to add the commit identifiers in the commit messages |
| | 69 | |
| | 70 | ''Ryosuke:'' But I want to see identifiers in git blame |
| | 71 | |
| | 72 | ''Jonathan:'' GitHub doesn’t support this, the only solution would be to self-host the repo and figure out how to change the UI |
| | 73 | |
| | 74 | ''Alexey:'' We don’t want to get rid of trac, we just don’t expect it to work well with GitHub. If we can find a way to keep it working, we’ll leave it, but it won’t support commit identifiers |
| | 75 | |
| | 76 | ''Ryosuke:'' i want an interactive solution that works with source tree, otherwise this is only half functional |
| | 77 | |
| | 78 | ''Ryosuke:'' The proposed solution requires me to follow 5 or 6 different links |
| | 79 | |
| | 80 | ''Jonathan:'' The most practical solution may be a client-side plugin or extension. Given a hash it is trivial to convert it to an identifier, we just need something to do it. |
| | 81 | |
| | 82 | ''Ryosuke:'' That would be an acceptable solution to me. |
| | 83 | |
| | 84 | ''Maciej:'' I just tried git blame and it doesn’t show the identifier, just a short commit message and how many years ago to the side of the line. |
| | 85 | |
| | 86 | ''Maciej:'' When you hover on the commit message, it shows the full commit message which should include our commit identifier, so this may not be an issue with the GitHub blame. |
| | 87 | |
| | 88 | ''Sam:'' GitHub blame should include the date by default. |
| | 89 | |
| | 90 | ''Maciej:'' Question/''comment:'' What exactly does it mean to support bugzilla patch review and pull requests? Ultimately, things have to be pull requests or we support direct commit to protected branches. I wouldn’t want everyone to be able to direct commit just because they say they got a bugzilla review. It would be confusing to have two review systems. |
| | 91 | |
| | 92 | ''Jonathan:'' Since we have a commit queue handling the landing of patches, we intend to take that away. |
| | 93 | |
| | 94 | ''Maciej:'' We should have a plan to phase out the patch system, it doesn’t make sense to have two forms of patch review for the indefinite future. Maybe others have different opinion. |
| | 95 | |
| | 96 | ''Aakash:'' If we keep security bugs in bugzilla, we need both forms indefinitely. |
| | 97 | |
| | 98 | ''Jonathan:'' The concern is forcing people to think about both systems, not necessarily supporting code for both systems. Maybe we just disable patch review for non-security bugs? |
| | 99 | |
| | 100 | ''Maciej:'' Once a thing has been r+d, we don’t have to keep it secret anymore. We want things to be hidden until we are ready to land it. GitHub private repos don’t give us the properties we want, we will probably have to talk to them about that. If security fixes have to be weird, those who deal with them habitually may have to just deal with that. |
| | 101 | |
| | 102 | ''Jonathan:'' Losing EWS for security fixes would be undesirable. |
| | 103 | |
| | 104 | ''Jen:'' Drupal went through similar considerations 10 years ago, we may be able to learn from them. |
| | 105 | |
| | 106 | ''Simon:'' Do we also plan to remove the trac wiki? That is where we have been keeping contributor meetings notes. |
| | 107 | |
| | 108 | ''Jonathan:'' We should move to the GitHub wiki, but we haven’t looked at it deeply enough to see what it would entail. We intend to migrate it somewhere, ideally GitHub. |
| | 109 | |
| | 110 | ''Simon:'' We would keep trac running for wiki even if we use it for SVN? |
| | 111 | |
| | 112 | ''Jonathan:'' Yes |
| | 113 | |
| | 114 | ''Ryosuke:'' There was a discussion about fork vs non-fork for PR, do we have a resolution there? |
| | 115 | |
| | 116 | ''Jonathan:'' We don’t have a resolution, it doesn’t make sense to forbid it. My sense is that being a committer lets you create unprotected branches, which is what GitHub access allows, but we will end up with a large number of branches. We’ll need to follow up to see if that bothers people. |
| | 117 | |
| | 118 | ''Ryosuke:'' I hate seeing all the branches on large GitHub projects with incomprehensible names. |
| | 119 | |
| | 120 | ''Jonathan:'' We will have some system to clean up branches. |
| | 121 | |
| | 122 | ''Maciej:'' One approach to avoid superfluous branches could be for commit queue to delete PR branches immediately. If we need them to stick around for some time for reference, we could delete them after some delay. |
| | 123 | |
| | 124 | ''Jonathan:'' Another approach is that we could have an old PRs header in our branches (i.e. old/<name>), so we can group them and hide them from searches. That would keep them around but won’t pollute everyone’s history |
| | 125 | |
| | 126 | ''Christopher:'' Will the current git webkit mirror be replaced with new commits? |
| | 127 | |
| | 128 | ''Jonathan:'' It will be replaced. It was originally http, tried changing it to https which didn’t work (and changed commits). I have a git clone of WebKit that I am adding commit identifiers to and updating committers. I will publish that as the canonical repository. |
| | 129 | |
| | 130 | ''Michael:'' I wanted to mention that GitLab lets you host your projects. If you pay for a private fork of a project, it supports confidential merge requests that can target that private fork. It may not have the fine grained control that you are looking for. |
| | 131 | |
| | 132 | ''Alexey:'' We need to talk to GitHub about their ideas for how to solve it. We don’t have a crazy demand that wouldn’t apply to anyone else. |
| | 133 | |
| | 134 | ''Jonathan:'' I am working on talking with GitHub folks about this, but no updates to share. |
| | 135 | |
| | 136 | ''Ryosuke:'' I really hate git. The only reason we should move to git is if we are going to use GitHub. If we aren’t moving there, it isn’t worth it. |
| | 137 | |
| | 138 | ''Jonathan:'' We are slowly losing support for SVN on the platforms we develop for |
| | 139 | |
| | 140 | ''Jonathan:'' There are also lots of CI systems that are having trouble with supporting SVN, or don’t support it at all |
| | 141 | |
| | 142 | ''Alexey:'' Does anyone in this group have tools that we aren’t thinking about needing to update? |
| | 143 | |
| | 144 | ''Don:'' No affected tools on the Sony side, but the changing git hashes will impact us. |
| | 145 | |
| | 146 | ''Alexey:'' Can we do anything to help? |
| | 147 | |
| | 148 | ''Don:'' We’re only finding out about it now, haven’t yet talked about it as a team. We would definitely prefer a pure git repo, especially because not all safari branches are mirrored in the git repo. |
| | 149 | |
| | 150 | ''Sam:'' Git replace exists, which may allow you to keep the existing history |
| | 151 | |
| | 152 | ''Jonathan:'' I’m not sure if git replace is sufficient, I’ll double check. One problem is that already have two sets of hashes because of the http / https clones. |
| | 153 | |
| | 154 | ''Don:'' is the WebKit org going to be used for anything other than the WebKit repo? |
| | 155 | |
| | 156 | ''Jonathan:'' I’m not sure |
| | 157 | |
| | 158 | ''Jonathan:'' Tess, is the WebKit org going to be used for anything else (such as the feature status you discussed yesterday?) |
| | 159 | |
| | 160 | ''Tess:'' Yes, that would make sense |
| | 161 | |
| | 162 | ''Don:'' Are we going to use any existing GitHub integrations/apps (there is one to delete pull request branches). Are there any requirements for hosting our own tools around GitHub? |
| | 163 | |
| | 164 | ''Jonathan:'' There is interest, but we haven’t made any plans as many of them don’t come in to play until we use pull requests and github issues. We also need to get clarification from GitHub about API requests that we need to consider when building our own automation. Bug I am absolutely interested in not rebuilding things that already exist. |
| | 165 | |
| | 166 | ''Don:'' Ok cool, just wanted to make sure it was on the table. |
