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

[Philip Reames via llvm-dev]

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>