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

[Eric Christopher via llvm-dev]

FWIW I'm with Mehdi here.

On Sat, Feb 29, 2020, 8:07 PM Mehdi AMINI via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> On Tue, Feb 25, 2020 at 4:19 AM Christian Kühnel via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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.
>>
>
> I still feel this is only a recipe for confusion if "some" pull-requests
> are accepted on Github but not all. So -1 from me on this.
>
>
>>
>> @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.
>>
>
> You seem to be arguing the "how to transition" while there is no agreement
> on a transition happening in the first place.
>
>
>> We're also too large to follow a one-size-fits-all approach. If we agree,
>>
>
> I don't: we went with a monorepo because we believed that the
> one-size-fits-all would be more beneficial than splitting, both in terms of
> infrastructure, but also in terms of the practices of the community, etc.
>
> 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.
>>
>
> One aspect here though is that we can pay someone to build the things we
> need in Phabricator, we can't change GitHub though.
> It was mentioned in the past that we should engage with GitHub and see if
> they would add the feature we're missing to their roadmap, if it hasn't
> been done I'd start there: building up this list of things that need to
> happens before we can agree towards a transition, and engaging with GitHub
> to have these.
>
> --
> Mehdi
>
> _______________________________________________
> 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/20200301/dd2fe3b6/attachment-0001.html>