">

(original) (raw)



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


On Wed, Jul 1, 2020 at 10:20 AM Philip Reames via llvm-dev <llvm-dev@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@apple.com> wrote:



On 2020-Jun-30, at 13:28, Chris Lattner via llvm-dev <llvm-dev@lists.llvm.org> wrote:

On Jun 29, 2020, at 10:15 PM, Chandler Carruth via llvm-dev <llvm-dev@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@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev