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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4