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

Tue Jul 14 20:41:49 PDT 2020

On Tue, Jul 14, 2020 at 5:23 PM James Y Knight via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Wed, Jul 1, 2020 at 4:19 PM James Y Knight <jyknight at google.com> wrote:
>
>> The consequences of pushing a new branch name and then deleting it later
>> should be low. And if we really wanted to exclude it from the default pull
>> set, it can be placed in, "refs/staging/apple" instead of
>> "refs/heads/staging/apple". Nothing outside refs/heads/ and refs/tags/ gets
>> pulled by default. This *should* be the obvious answer. However, we've
>> had cases in the past that when people have accidentally created a branch
>> or opened a pull request (which creates a new branch in "refs/pull/NNN"),
>> which triggered phabricator to start sending a bunch of effectively-spam
>> emails. I believe that may still be a problem.
>>
>> Unless someone can confirm that this *won't* happen, it's probably *not* a
>> good idea to push 30,000 "new" old commits into any branch in the repo.
>>
>
> Well, I can now confirm that this in fact does still happen. The creation
> of https://github.com/llvm/llvm-project/pull/232 has triggered
> phabricator to send out emails notifying me of my commits that were in
> there, as if they were actually committed to a real branch. I assume the
> same occurred for others. This is really unfortunate behavior, and I do
> hope we can figure out how to configure phabricator to stop doing this.
>

I looked into Phabricator config: right now we have to either track all
branches or list explicitly the branches to track (which require a config
change every time we create a new release branch).
I can set it up with master and the most recent release branch for now?

More recent versions of Phabricator have more fine grain control (I need to
upgrade...)

-- 
Mehdi

>
> But...now it's been done. So I guess that's that! The apple branch is in
> github.com/llvm/llvm-project (in branch refs/pull/232/head; you can
> checkout via `git fetch origin refs/pull/232/head && git checkout
> FETCH_HEAD`).
>
> I'd also concur with the other comments that it really feels quite silly
>> to do have to do anything technical here at all, versus posting an email to
>> llvm-dev along the lines of "Apple is contributing the code added in
>> github.com/apple/llvm-project, commit hash
>> a1fde6dadf210c937c88509ab775610213e2cfc5, and all prior commits it depends
>> on, under the Apache2 license with LLVM project exceptions, as listed in
>> https://github.com/apple/llvm-project/blob/a1fde6dadf210c937c88509ab775610213e2cfc5/LICENSE.txt".
>> That seems like it'd be sufficient -- and even more explicit as a statement
>> of intent than creating a branch! (But, of course, IANAL).
>>
>
>> Or -- how about both sending such a message *and* creating a phab review
>> for `git diff origin/master...swift/apple/master` (three dots diff gets the
>> diff only from the last merge-point). Maybe that covers all the bases
>> sufficiently?
>>
>> On Wed, Jul 1, 2020 at 1:19 PM 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?
>>>
>>> Philip
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> 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/20200714/1ae72eda/attachment.html>