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

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Wed Jul 1 10:19:44 PDT 2020


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 
>> <mailto:dexonsmith at apple.com>> wrote:
>>
>>
>>
>>> On 2020-Jun-30, at 13:28, Chris Lattner via llvm-dev 
>>> <llvm-dev at lists.llvm.org <mailto: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 <mailto: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?

Philip


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


More information about the llvm-dev mailing list