What is the replacement for Herald so that people can be automatically added to code reviews in their area of interest?
Anton gave some update on this topic, but my recollection is that we don’t have a great solution to this yet.
What is the replacement for Phabricator’s list of active/open reviews?
I searched “github dashboard” and found some docs referring to such functionality: “You can visit your personal dashboard to keep track of issues and pull requests you’re working on or following” Does that sound sufficient?
Will we be documenting best practices where we need a replacement for code review activities that are not supported by GitHub? e.g., best practices for leaving comments on lines of code that are unchanged in the review, reminding people that GitHub hides the most relevant changes in the review by default sometimes, what to do when your code review no longer loads because it has “too many comments”, etc
We should always document best practices. Who is “we” in your question? I don’t expect these practices and documents can be produced without more experience with pull requests. I hope that the subprojects who trial run code reviews will help us generate the necessary experience to produce these docs.
Are we changing permissions/processes as part of this transition? e.g., are code owners going to be required to sign off on a review before it can be merged or continuing to allow anyone to merge? Are we changing who can make labels or introduce milestones/projects in the issue list? etc
I haven’t heard anyone propose a change to the LLVM approval or permission model so far. I think the transition is limited in scope to just replacing the code review tool.
Do we have what we need to continue to report commits to the cfe-commits and llvm-commits mailing lists once we cut over to GitHub?
As far as I know, we already report commits to the lists. Maybe your question is, will every pull request send an email to a -commits list? I think this is an open question, I don’t have an answer.
How are we preventing new patches from being submitted via Phab after Sep 1?
I think the plan is to allow patch submission on Phab during the transition so that if the new process isn’t working, we can still fall back to the old process.
What is the plan for (active) open code reviews on Phabricator that are not completed by Oct 1? (Even with cutting off new patch submission on Sep 1, there will be patches that aren’t cleared by Oct 1.) I’m not worried about reviews that have gone stale from years ago as those can be recreated and linked-to from a new PR as appropriate.
Phabricator supposedly supports a simple readonly mode, and that’s what I propose we use. We could try to hack Phabricator’s PHP code to block new patch submission, and add an extra phase where comments are allowed before going fully readonly on Nov 1 or something like that. This is extra work, though, and it doesn’t seem necessary to me. Do you feel it is important, or would you rather extend the window of overlap to allow active reviews to finish?
Is the LLVM Foundation communicating directly with major downstream vendors to ensure that this timeline works for them?
Other than these announcements, I’m not aware of other direct communications.
What is the fallback plan if any of our steps runs into problems that we can’t solve on the expected timeline? Are we going to forge ahead regardless, or is there wiggle room to delay steps as needed?
I think the backup plan is to push back the Oct 1 Phabricator readonly cutoff date. If pull requests are really a showstopper, that seems like the most reasonable release valve.
We’ve switched infrastructure previously (email to phab for code reviews, svn to git, bugzilla to github, etc) so there’s every reason to believe we’ll switch again in the future; are we confident we can move our data back out of GitHub when we need to? I believe we can for things like issues, but I don’t have any insight into how plausible that is for code reviews (e.g., can we get a static HTML archive of reviews should we need to make this same transition again in the future?)
That’s a good question. I certainly link to Phabricator review threads to reference the comments and reasoning for our past decision making. I believe pull requsts are part of the github issue tracker, so any export of issue tracker data presumably includes pull request comments.