To give an update on the Oct 1 deadline, we haven’t found the time to disable the diff upload functionality. I made a test differential, D159552, to confirm. It turns out that the last differential before mine, D159551, was uploaded at the end of September. So, I guess I’ll take that as a sign that everyone is working together to support the migration, and express my thanks for that.
Given that we have successfully migrated to PRs thus far and don’t appear to be fragmenting the code review ecosystem, I’m considering skipping the step where we disable patch uploads altogether, and go directly to disabling the git import some time before the holidays. The goal is to make sure that Phabricator is in a low-maintenance mode before 2024.
To restate the tentative schedule:
Dec 15: Stop importing new commits from github
Remain in this state for at least 6 months. Comments are allowed.
Regarding updates to the banner text, feel free to suggest more precise, concise text that discourages folks from migrating in-progress reviews to pull requests.
Regarding reviews still in the queue, hopefully what I’ve said above addresses that concern.
Regarding the “static” version of Phabricator, I don’t have any updates yet.
I have disabled new revision creation. I have tested that updating an existing differential (arc diff 'HEAD^' ) still works.
Disabling differential updating can be achieved by editing neighbor lines in src/applications/differential/editor/DifferentialRevisionEditEngine.php.
Perhaps importing new commits from github can be postponed when the site eventually becomes read-only? Otherwise we lose connections from main branch commits to referenced differentials.
Current Login says Fetch Refs: refs/heads/*, refs/tags/*.
We have user-branches opened in the repo, so we can now replicate the same workflow we had in Phabricator. This can be done manually, but there are tools which handles it pretty well, like Introduction - spr Documentation (the doc even mentions arc!).
The next step is making sure we don’t accumulate branches, which can be done through some automation (GitHub action likely) which:
periodically delete branches not associated with an open pull-request.
closes PR coming from such branch without any activity after some time.
There’s a GitHub setting that does this automatically. I think we should enable that (if it isn’t already), as 9 times out of 10, people forget to click the button, if experience from one of our company repos is anything to go by, resulting in the accumulation of numerous branches and eventually a “mass purge” (automation can help with that admittedly, but the option is better, if not sufficient to cover all cases). I’ve had this option enabled in a repo I administer for a small team at our company and there’s been zero negative impact in having it enabled that I know of.
I actually installed the “other” one first and was confused when the docs did not line up. This likely can’t be resolved easily, but as long as we very clearly document how to get the right version (and maybe include a “warning” callout about the existence of another similar project in those docs) it shouldn’t be an issue.
The reason I started with the “wrong” project was due to the limited supported install methods for Linux, which involve either:
Installing brew for Linux, and using it to install additional copies of things like glibc to satisfy the particular symbol version requirements of the “bottle” binary package
Installing an entire rust toolchain and building from source
Neither sounded appealing. In general these kinds of projects have “Releases” on github that can be downloaded directly, so I tried to find that page and wound up in the wrong place.
Granted many LLVM devs will already have one of these, but it would be nice to have something where the average user avoids the extra steps of setting up an entire package manager or language toolchain just to work on LLVM. Maybe we could reach out to the devs and see about adding more binary Releases to the github? As a rust project it seems like it should be able to target a pretty old glibc and be runnable on “any” modern Linux system as a single binary.
Maybe this is a non-issue? Does anyone have any thoughts?
The link in the banner on reviews.llvm.org is pointing to the beginning of this thread, showing the original timeline. I don’t think that timeline is valid any longer, and IMO it is a bit hard to scroll around to find the currently proposed timeline.
Not quite sure, but is it possible to pin the current timeplan (if there is any) to the top of the thread somehow?
SPR creates a branch per patch in the stack. The only first patch is PR from the branch into main, all other PR between branches. So if you use that button, it pushes from one of my branch into another.
Now when I know that, and can avoid that by changing destination of the PR in the webui, or by using SPR to land. But I can’t expect that from reviewers, if they decide to merge patch for me.
The intent is that when you have a stack, you merge these in order, and in this case the UI handles this correctly for you
(we can also easily add a check that blocks merge of PRs that don’t target main to avoid people merging out of order without updating the target branch).
Here is the flow, base of the stack is pr1 to main:
When I click “squash and merge” in the UI for pr1 it gets merged to main (as expected), the branch pr1 is automatically deleted (because the branch is in the repo), and without any action of mine pr2 is retargeted to main, as visible in the UI:
The typical Github workflow is to create a fork of the monorepo, push your changes to a branch in your fork, and then open a PR from that branch into the main repository. Documentation on this workflow is available here.
It’s kind of out of date already as the users/ namespace is opened up to enable stacked pull requests, but that doesn’t seem to be what you’re aiming to do (but the docs should be updated).
