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

[Stella Laurenzo via llvm-dev]

On Wed, Jul 1, 2020 at 1:27 PM Mehdi AMINI via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> On Wed, Jul 1, 2020 at 10:20 AM Philip Reames via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>> On 6/30/20 2:07 PM, Chris Lattner via llvm-dev wrote:
>>
>>
>>
>> On Jun 30, 2020, at 2:02 PM, Duncan Exon Smith <dexonsmith at apple.com>
>> wrote:
>>
>>
>>
>> On 2020-Jun-30, at 13:28, Chris Lattner via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> On Jun 29, 2020, at 10:15 PM, Chandler Carruth via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>
>> IMO, a pull request isn't as clear given that they haven't been used for
>> contributions before. This is not a time to be innovative IMO. A branch as
>> a staging location has been used many times over the history of the project
>> though and seems nicely unambiguous in that regard.
>>
>>
>> I don’t have a opinion on this either way, but can git/GitHub maintain
>> forks within the same organization?  You could have llvm/llvm-project and
>> llvm/llvm-project-apple-staging or something like that?
>>
>>
>> I don't think GitHub allows you fork your own repo so I think it would be
>> disconnected from a GitHub point of view. That has a few downsides,
>> although I'm not sure how important they are.
>>
>> Regardless, if a separate repo is preferred, then a better name from our
>> perspective would be "llvm-project-staging" (dropping the "-apple" suffix).
>> We could push a "staging/apple" branch there.
>>
>>
>> Ok, I’m not very concerned either way, it was just a thought.  I’m very
>> happy to see this upstreaming work happen, thanks!
>>
>> -Chris
>>
>> I have a mild preference for the separate llvm-project-staging approach,
>> but am not opposed to an in tree branch either.  The main argument I see
>> for the separate repo is that the bar can be lower because the consequences
>> for being "wrong" about the code being fully merged quickly are lower.
>>
>> Or another thought, maybe we should even use the incubator flow here?
>> Nothing says an incubator has to be long lived.  If we spun up an
>> "incubator-staging-apple" repo, wouldn't that demonstrate the same benefits?
>>
> I am not convinced the "incubator" proposal is suited for this purpose as
> this is not about a new project but about a patch on top of LLVM itself. My
> understanding of the incubator is to build new project/subprojects, but not
> to diverge from LLVM itself (if it isn't clear in the current proposal we
> should discuss it and clarify it, either way we end-up).
>

The "incubator" does not need to be (and shouldn't be) the only way to
create a new repo in the LLVM org. If there is a pragmatic need for a new
utilitarian repo that fits outside of that process, then that seems like
something that the community can decide to do at any time without further
consequence.


>
> --
> 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/20200701/7902b413/attachment.html>