[llvm-dev] Allowing PRs on GitHub for some subprojects

[Christian Kühnel via llvm-dev]

Hi Louis,

I think this is a good idea. We should start with some local experiments
where people are willing to try it and figure out how well that works and
what does not. Why not allow this for "not significant" changes? They are
merged without review today, so we could do them with reviews (and
automated tests) via pull requests instead.

@Mehdi

> - it does not favor to build common tooling: the recent work on enabling
> pre-submit CI tests on Phabricator is valuable and I'm looking forward to
> get this extended. But splitting the various ways of contributing to the
> repo just means more infrastructure to build to sustain this kind of
> efforts. (the infrastructure is easier built on GitHub by the way, but
> that is an argument in favor of migrating from Phab to GH for the
> full-project).
>

Oh I'm happy to add Github support as soon as someone switches on PRs. This
is soooooo much easier to set up and maintain than the Phabricator
integration. And we already have builds for the release branch (
https://buildkite.com/llvm-project/llvm-release-builds) anyway. So we could
easily scale that up. And we can only get pre-merge testing on Phabricator
to a certain point, as it's not triggering builds for ~50% of the code
reviews.

@Chris Lattner

> Although I am one of the (many) people who would love to see us move from
> Phabricator to GitHub PRs, I think it is super important that we do the
> transition all at once to keep the LLVM community together.  I’m already
> concerned about the fragmentation the discourse server is causing, e.g.
> MLIR not using a -dev list.  I’d rather the community processes stay
> consistent.
>

Please allow me to disagree there. IMHO we're way too large and diverse of
a project to do binary, overnight transitions. We're also too large to
follow a one-size-fits-all approach. If we agree, Github PRs are the right
glow, why take this step-by-step. We should have something like a list of
important and supported use cases/interactions for the infrastructure. Then
we could start working on them one-by-one and figure out if/how they could
be implemented on Github and how we could do a smooth transition between
these.

If Herald rules are important: Find a way to implement something similar
for Github. Maybe there is even a market for such a tool.
If transparency is the problem: Find a way to mirror PRs into Phabricator,
so people can at least see them there.
We're not restricted to community contributions there. We can also pay
someone to build the things we need.

Best,
Christian


On Thu, Feb 20, 2020 at 7:21 PM Louis Dionne via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
>
> I know there has been significant discussion about "moving" from
> Phabricator to GitHub reviews and pull requests, etc. I'm not suggesting
> that we do anything in terms of global LLVM policy. However, as a
> maintainer of libc++, I commit __a lot__ of other people's code for them.
> It would be a huge time saver for me if I could nicely suggest to
> contributors (not force them) to use PRs instead of Phabricator for their
> contributions. It would also handle commit attribution properly, which is a
> pain right now.
>
> Would it be possible to allow GitHub PRs to be submitted on the monorepo
> so as to let individual sub-projects deal with it however they please? I've
> spoken to numerous people involved in libc++ development and they would
> like to start submitting PRs (and for the others, we'll still accept
> Phabricator reviews). Perhaps it is possible to setup some kind of filter
> such that PRs touching only libcxx/ and libcxxabi/ can be submitted, but
> otherwise they're closed by the bot?
>
> Cheers,
> Louis
>
> _______________________________________________
> 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/20200225/2da96d9e/attachment.html>