I would say that we've found a reasonable solution, and that we should run with it. I see minimal value in trying to optimize this situation further. Philip On 7/9/20 1:33 AM, Mike Forster via llvm-dev wrote: > Essentially this decision is balancing legal risk with > inconveniencies, which is a tough trade-off to consider. > > It seems to me that the extra repository would be a compromise that > gets the balance right. Sure, there are some drawbacks, but the legal > story is quite straightforward and clear. This is something where I'm > tempted to trust the lawyers and avoid experiments. > > I would also like to congratulate Apple to make the decision to > contribute their LLVM changes back to the community, and I think we > should be welcoming and make this straightforward for them. > > Just my 2¢. > > On Thu, Jul 9, 2020 at 10:13 AM Roman Lebedev via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On Thu, Jul 9, 2020 at 4:36 AM James Y Knight via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > As noted in the other thread, making a new repository under the > same user, which therefore must be unrelated to the original, > seems to have downsides as far as commit duplication on github. > Probably the downsides of that are non-critical (and less bad than > a bunch of email spam), but it's still unfortunate. > +1, i was asking about that in "[llvm-dev] Why is there a > llvm/apple-llvm-project-staging ?" > https://lists.llvm.org/pipermail/llvm-dev/2020-June/142559.html > > Roman > > > It still very much feels to me that the best answer should be to > do none of the above, and rather to explicitly contribute the > desired changes without needing the technical step of pushing the > commits somewhere in github.com/llvm/ <http://github.com/llvm/>. > Is that truly non-viable? The "plain" non-lawyer reading of the > license does not appear to privilege a "contribution" which is > done via "git push", vs a contribution done via emailing a > statement that you contribute git hash <X>, found at <url> to the > mailing list. > > > > > > On Wed, Jul 8, 2020 at 8:00 PM Duncan Exon Smith via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> > >> Okay, a separate repo called "llvm-project-staging" (and a > branch called "staging/apple") seems to be the consensus. We'll > move ahead with that! > >> > >> On 2020-Jul-08, at 05:38, Mike Forster <forster at google.com > <mailto:forster at google.com>> wrote: > >> > >> The downsides of an additional project are small. I can see: > >> 1) It's not possible to do pull requests from there, because > GitHub won't treat it as a fork. > >> 2) It's still visible to people > (http://lists.llvm.org/pipermail/llvm-dev/2020-June/142559.html) > >> > >> In the end I don't have a strong opinion on whether this is a > branch or a repository, as long as we move ahead soon. > >> > >> On Thu, Jul 2, 2020 at 4:29 PM Johannes Doerfert via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >>> > >>> > >>> On 6/30/20 4:02 PM, Duncan Exon Smith via llvm-dev wrote: > >>> > 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. > >>> > >>> +1 for a separate repo with a neutral name and "company" branches. > >>> > >>> > >>> * Unlikely we spam people > >>> > >>> * Easy to understand from the github page > >>> > >>> * Invisible to the existing users of llvm-project/llvm > >>> > >>> * Unlikely to confuse people that have or download llvm > (=accidental > >>> build of staging/apple) > >>> > >>> > >>> I haven't really seen a downside, though I might have missed > something. > >>> > >>> _______________________________________________ > >>> LLVM Developers mailing list > >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > _______________________________________________ > 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/20200709/827b56c9/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