Hi all,
I filed https://bugs.llvm.org/show_bug.cgi?id=47934 asking to have
the debuginfo-tests project added to the list of those that subscribe
llvm-commits automatically. But, it appears that the Phabricator
component doesn't have anyone automatically cc'd, and I suspect that
by failing to put [Phab] in the bug title, whoever knows how to do
this won't notice the bug.
So, how does that auto-subscription work? Note that historically,
I have always come out the worst when tangling with Phabricator...
so I'll do it myself if necessary, if someone can say what "it" is,
but it would be safer for someone else to do the tweaking.
Will follow-up more on the bug, but I don’t think the commits mailing list mail is powered by phabricator at all - it’s some post-commit hook in the VCS/github itself, I think.
I’m talking about the “subscribed” field in a Phab review, so that the list sees the posted comments/reviews; you seem to be talking about the “this was committed” email which does come from github.
These are all plugged through global Herald rules in general.
It somehow relies on the monorepo to know how to dispatch (path starting with LLVM → llvm-commits@).
I don’t know what the rule should be for debuginfo-tests?
These are all plugged through global Herald rules in general.
It somehow relies on the monorepo to know how to dispatch (path starting with LLVM → llvm-commits@).
I don’t know what the rule should be for debuginfo-tests?
Same as LLVM I think would be good. (that’s where the commits mail is going, pretty sure - so it’s where the reviews should go)
These are all plugged through global Herald rules in general.
It somehow relies on the monorepo to know how to dispatch (path starting with LLVM → llvm-commits@).
I don’t know what the rule should be for debuginfo-tests?
Same as LLVM I think would be good. (that’s where the commits mail is going, pretty sure - so it’s where the reviews should go)
I mean: I don’t know how to detect that a patch is about the debuginfo tests: if it is another repo, there won’t be a leading path to tell us like in the monorepo.
These are all plugged through global Herald rules in general.
It somehow relies on the monorepo to know how to dispatch (path starting with LLVM → llvm-commits@).
I don’t know what the rule should be for debuginfo-tests?
Same as LLVM I think would be good. (that’s where the commits mail is going, pretty sure - so it’s where the reviews should go)
I mean: I don’t know how to detect that a patch is about the debuginfo tests: if it is another repo, there won’t be a leading path to tell us like in the monorepo.
Oh, sorry, I see - any idea how mlir, flang, etc, handle this then?
These are all plugged through global Herald rules in general.
It somehow relies on the monorepo to know how to dispatch (path starting with LLVM → llvm-commits@).
I don’t know what the rule should be for debuginfo-tests?
Same as LLVM I think would be good. (that’s where the commits mail is going, pretty sure - so it’s where the reviews should go)
I mean: I don’t know how to detect that a patch is about the debuginfo tests: if it is another repo, there won’t be a leading path to tell us like in the monorepo.
Oh, sorry, I see - any idea how mlir, flang, etc, handle this then?
Like LLVM: by being in the monorepo they have a leading path discriminator.
Oh, right, sorry, was getting things confused/mixed up about “is it part of llvm, is it part of the monorepo, is it in another repo”. Dunno what to do about that then.
Hmm, wait, no - nevermind that. These tests are part of the monorepo:
Dunno what to do about that then.