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

[Mehdi AMINI via llvm-dev]

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).

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