[llvm][docs] Add notes on upstreaming code from downstream projects

[banach-space]

For context, see:

• https://discourse.llvm.org/t/code-review-process-when-upstreaming-patches

[chelini]

Thanks!

[hubert-reinterpretcast]

The straight-forward reading of this does not cover the situation where an employee develops code for an employer and the employer directs another employee to work on the upstreaming (potentially after the employee who wrote the code is not longer employed with the employer).

[hubert-reinterpretcast]

Similarly to the employer/employee scenario, a contributor to a Downstream Community project may have distanced themselves from said Downstream Community. Said Downstream Community, if their licensing is compatible, need not be beholden to the individual contributor as to whether or not the code is upstreamed.

[banach-space]

Thanks for raising this! Admittedly, I hadn’t really considered the employer-employee relationship in this context. That said, should LLVM’s Code Review policies (or any other Open Source project) mandate, guide, or influence what that relationship should be?

Let me clarify where I was coming from when writing this. My focus was on cases where some code exists in an Open Source repository, and a community volunteer decides to move that code from the downstream project to LLVM - either with or without additional changes. To me, it seems natural that the original author should be consulted, and that any changes should be properly attributed in such cases.

Regarding your point about employer-employee relationships, I’m not sure what we could add to make this clearer, as it seems highly context-dependent. And very different to what I originally had in mind. Are there any specific licensing and/or copyright issues that we should consider? I’d hope that the existing LLVM Developer Policy is sufficient here.

Ping @kbeyls , who has spent a considerable amount of time on LLVM's relicensing and is my go-to expert this kind of things.

[hubert-reinterpretcast]

The straight-forward reading of this precludes approval of code where all of the qualified experts were involved in the development of the code. Is a code owner for a component or the lead for a specific platform (e.g., for Clang driver changes for that platform) unable to give approval to land a change if they developed part of it?

[banach-space]

Is a code owner for a component or the lead for a specific platform (e.g., for Clang driver changes for that platform) unable to give approval to land a change if they developed part of it?

Wouldn’t this essentially equate to self-approving your own code?

LLVM's developer policy already allows one to commit patches without review in certain cases:

• https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access

You are allowed to commit patches without approval which you think are obvious.

When we do this, it's effectively self-approval, but the intent is clear - we typically justify direct pushes with reasons like "trivial typo" or "fix broken bot to unblock people."

I’d prefer to avoid creating a new category of "code-owner reviewing their own code submitted by another community member." That seems like an unnecessary distinction and could blur the lines of our review process.

[hubert-reinterpretcast]

It's not necessarily the same as self-approval though. For example, the person could have been involved in the downstream development, but perhaps only for a limited part of the whole patch.

If the community relies upon or generally defers to said person for the approval of patches in the area being modified, it stands to reason that, absent comments from other reviewers within a reasonable wait period, their approval should be considered valid for landing the change (if they indicate that to be their intent).

[banach-space]

I've added Kristof as a reviewer. Kristof added the existing note on using GitHub's Co-authored-by:

• llvm-project/llvm/docs/DeveloperPolicy.rst

  Line 409 in cd3acd1

  In the rare situation where there are multiple authors, please use the `git