This is an archive of the discontinued LLVM Phabricator instance.

[Bazel] Update for 6103fdfab4
ClosedPublic

Authored by GMNGeoffrey on Jul 19 2021, 11:49 AM.

Details

Summary

Update Bazel config for
https://github.com/llvm/llvm-project/commit/6103fdfab4
by deleting the llvm-elfabi target.

Diff Detail

Event Timeline

GMNGeoffrey requested review of this revision.Jul 19 2021, 11:49 AM
GMNGeoffrey created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJul 19 2021, 11:49 AM
This revision was not accepted when it landed; it landed in state Needs Review.Jul 19 2021, 11:51 AM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.

Generally if something's sent for review, it should wait until it's approved before committing - but not everything needs to be sent for review. Changes to the Bazel BUILD files seem to be fine to be committed directly/for post commit review, especially by you :)

Generally if something's sent for review, it should wait until it's approved before committing - but not everything needs to be sent for review. Changes to the Bazel BUILD files seem to be fine to be committed directly/for post commit review, especially by you :)

Ah I was seeking post-commit review, but wanted to land this trivial fix to unbreak things. What is the right way to say "please review this post-commit" then?

Generally if something's sent for review, it should wait until it's approved before committing - but not everything needs to be sent for review. Changes to the Bazel BUILD files seem to be fine to be committed directly/for post commit review, especially by you :)

Ah I was seeking post-commit review, but wanted to land this trivial fix to unbreak things. What is the right way to say "please review this post-commit" then?

I sometimes include some callout in the commit message "I'm open to other ideas/feedback" or the like (were there any particular questions/aspects of review you wanted to get a second set of eyes on?) - or a reply to the commit email (or on the phab commit entry - though personally I prefer the commit email, since that's the authoritative record & replying to the phab commit entry creates a completely different email thread/subject line, etc)

Generally if something's sent for review, it should wait until it's approved before committing - but not everything needs to be sent for review. Changes to the Bazel BUILD files seem to be fine to be committed directly/for post commit review, especially by you :)

Ah I was seeking post-commit review, but wanted to land this trivial fix to unbreak things. What is the right way to say "please review this post-commit" then?

I sometimes include some callout in the commit message "I'm open to other ideas/feedback" or the like (were there any particular questions/aspects of review you wanted to get a second set of eyes on?) - or a reply to the commit email (or on the phab commit entry - though personally I prefer the commit email, since that's the authoritative record & replying to the phab commit entry creates a completely different email thread/subject line, etc)

Ah no I mean I want post-commit as opposed to pre-commit review because this change is trivial and should be uncontroversial :-D I deleted configuration for a target that was deleted.

The LLVM review process seems very weird to me, where review happens in one of several different places that aren't linked. I know I struggle when a commit doesn't have a phab review link attached (I'm not signed up for llvm-commits) and I can't figure out where I should mention some issue. https://llvm.org/docs/CodeReview.html#what-tools-are-used-for-code-review says that post-commit review can happen on phab, so I was attempting to create a place for that to be done in the same way as pre-commit review (I don't really see any reason why we'd want it to be split between tools). I'm of course fine doing whatever the generally-accepted practice in the community is, though threads like https://groups.google.com/g/llvm-dev/c/VTSwu2q5qnc suggest to me that there isn't really a generally-accepted practice.