[llvm-dev] RFC: Adding a staging branch (temporarily) to facilitate upstreaming

[Dmitri Gribenko via llvm-dev]

On Tue, Jun 30, 2020 at 7:48 PM Chandler Carruth via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Tue, Jun 30, 2020 at 10:11 AM Nicolai Hähnle <nhaehnle at gmail.com>
> wrote:
>
>> I'm mostly asking because we also have a fork of LLVM that we
>> continuously keep aligned with github.com/llvm/llvm-project/master
>> with the intention of deltas being broken out to be moved back
>> upstream. That branch is currently at
>> https://github.com/GPUOpen-Drivers/llvm-project, but if the LLVM
>> community decides that branches whose goal is to be contributed
>> upstream can (and should?) live in github.com/llvm/llvm-project, we'd
>> probably be interested in doing that and having a branch such as
>> amd/gfx-dev in the github.com/llvm/llvm-project repository.
>>
>
> See above -- I personally think this is an effective strategy when it
> solves a practical problem for people in the LLVM community at different
> organizations who want to collaborate on upstreaming something. I'd hope
> that anything like that was only done contingent on genuine interest in the
> community and with a pretty clear "it goes away" plan when merging stuff is
> complete.
>

I want to specifically emphasise the aspect of collaborating on
upstreaming. To collaborate, we need the code to be contributed to the LLVM
project first, even if it is not yet accepted into the master branch. If no
collaboration is necessary (that is, if the organization that originally
wrote the patches wants to upstream them) then there is no need to
contribute the code to LLVM project before commiting the code to the master
branch. The organization can work on the patch in their own repository to
prepare for upstreaming it .

Dmitri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200630/bebca852/attachment.html>