Johannes Doerfert via llvm-dev
2020-Jun-25 15:23 UTC
[llvm-dev] [cfe-dev] Phabricator Maintenance
On 6/24/20 3:41 PM, Chris Lattner via llvm-dev wrote:>> When I looked into this possibility (GitHub PR) when we merged MLIR in the monorepo: just Herald rules was already a blocker and I couldn't find a replacement readily available on GitHub. The handling of stack of revisions on GitHub was another problem mentioned. > Fair enough - I haven’t investigated the technical issues with adopting GitHub PRs for LLVM. My experience with the Swift community has been extremely positive though, I’d be surprised if there is something particularly crazy that only LLVM needs that GitHub hasn’t encountered. That said, again, I don’t have any practical experience with this part of the stack,I am very much relying on Herald rules to filter patches (=PRs). We need some replacement, IMHO, as we have many more patches/commits than swift and the mono-repo is more diverse (I would imagine). ~ Johannes> > -Chris > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200625/5d0efc30/attachment.html>
James Y Knight via llvm-dev
2020-Jun-25 16:33 UTC
[llvm-dev] [cfe-dev] Phabricator Maintenance
On Thu, Jun 25, 2020 at 11:24 AM Johannes Doerfert via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > On 6/24/20 3:41 PM, Chris Lattner via llvm-dev wrote: > > When I looked into this possibility (GitHub PR) when we merged MLIR in the monorepo: just Herald rules was already a blocker and I couldn't find a replacement readily available on GitHub. The handling of stack of revisions on GitHub was another problem mentioned. > > Fair enough - I haven’t investigated the technical issues with adopting GitHub PRs for LLVM. My experience with the Swift community has been extremely positive though, I’d be surprised if there is something particularly crazy that only LLVM needs that GitHub hasn’t encountered. That said, again, I don’t have any practical experience with this part of the stack, > > I am very much relying on Herald rules to filter patches (=PRs). > > We need some replacement, IMHO, as we have many more patches/commits than > swift and the mono-repo is more diverse (I would imagine). >Yes, but this part of the problem is trivial to solve. We can add a github workflow which triggers on pull-requests being uploaded or modified, which will @ people who ask to be, based on a configuration file matching commit paths/descriptions. There may even be something existing which does this, but even if not, it should be no more than a week to fully implement. If resolving this would actually let us migrate to GitHub, I'd volunteer to implement it myself, but it seems like there's other issues which are less trivial to solve that might also block it. ~ Johannes> > > -Chris > > > _______________________________________________ > LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200625/5443f61c/attachment-0001.html>
Johannes Doerfert via llvm-dev
2020-Jun-25 16:33 UTC
[llvm-dev] [cfe-dev] Phabricator Maintenance
On 6/25/20 11:33 AM, James Y Knight wrote:> On Thu, Jun 25, 2020 at 11:24 AM Johannes Doerfert via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On 6/24/20 3:41 PM, Chris Lattner via llvm-dev wrote: >> >> When I looked into this possibility (GitHub PR) when we merged MLIR in the monorepo: just Herald rules was already a blocker and I couldn't find a replacement readily available on GitHub. The handling of stack of revisions on GitHub was another problem mentioned. >> >> Fair enough - I haven’t investigated the technical issues with adopting GitHub PRs for LLVM. My experience with the Swift community has been extremely positive though, I’d be surprised if there is something particularly crazy that only LLVM needs that GitHub hasn’t encountered. That said, again, I don’t have any practical experience with this part of the stack, >> >> I am very much relying on Herald rules to filter patches (=PRs). >> >> We need some replacement, IMHO, as we have many more patches/commits than >> swift and the mono-repo is more diverse (I would imagine). >> > Yes, but this part of the problem is trivial to solve. We can add a github > workflow which triggers on pull-requests being uploaded or modified, which > will @ people who ask to be, based on a configuration file matching commit > paths/descriptions. There may even be something existing which does this, > but even if not, it should be no more than a week to fully implement.That would be great :)> If resolving this would actually let us migrate to GitHub, I'd volunteer to > implement it myself, but it seems like there's other issues which are less > trivial to solve that might also block it. > > ~ Johannes >> >> -Chris >> >> >> _______________________________________________ >> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>
Nathan Froyd via llvm-dev
2020-Jun-26 15:11 UTC
[llvm-dev] [cfe-dev] Phabricator Maintenance
On Thu, Jun 25, 2020 at 12:33 PM James Y Knight via cfe-dev < cfe-dev at lists.llvm.org> wrote:> > On Thu, Jun 25, 2020 at 11:24 AM Johannes Doerfert via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> We need some replacement, IMHO, as we have many more patches/commits than >> swift and the mono-repo is more diverse (I would imagine). >> > > Yes, but this part of the problem is trivial to solve. We can add a github > workflow which triggers on pull-requests being uploaded or modified, which > will @ people who ask to be, based on a configuration file matching commit > paths/descriptions. There may even be something existing which does this, > but even if not, it should be no more than a week to fully implement. > > If resolving this would actually let us migrate to GitHub, I'd volunteer > to implement it myself, but it seems like there's other issues which are > less trivial to solve that might also block it. > >It is not quite a full replacement for Herald rules, but Github supports labeling PRs depending on what files they modify: https://github.com/actions/labeler You can see it in action in the wasmtime repo, with its labels: https://github.com/bytecodealliance/wasmtime/blob/main/.github/labeler.yml and then using the subscribe-to-label action: https://github.com/bytecodealliance/subscribe-to-label-action people can get automatically CC'd to whatever areas they like. The only downside is that information lives in the repo itself, so people who want to be notified have to submit "fixes" to the repo. I know Herald lets you automatically add reviewers for given paths; it seems like that functionality ought to be supportable through Github actions as well. -Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200626/590ab902/attachment.html>