New candidate JEP: 369: Migrate to GitHub

[Kevin Rushforth]

You will need a personal fork of the repo, and you need to submit a pull 
request, but you can do that without ever visiting the GitHub web UI, 
using only the Skara command line tools, if you like.

Workflow could be:

file bug
create a branch in your personal fork
push fix to your branch of your fork
git pr create ...
<review happens, comments are addressed, approval(s) are given, etc>
git pr integrate

-- Kevin

On 11/22/2019 5:20 AM, Mario Torre wrote:
> What happens if I'm a committer then? Can I simply skip the github
> interface, the required public fork and instead just clone locally, do
> my work and commit?
>
> I.E. a workflow like this:
>
> file bug
> git clone directly-upstream-openjdk
> do some work && create webrev && send email request && get approval
> git push
>
> Or will I be forced to use the public fork and send PRs?
>
> Cheers,
> Mario
>
> On Sat, Nov 16, 2019 at 12:35 AM Kevin Rushforth
> <kevin.rushforth at oracle.com> wrote:
>> No, that isn't quite right. A contributor who has the role of Committer
>> is the one who initiates the commit, either via the GitHub UI, by
>> entering the "/integrate" command, or via the Skara tooling, by running
>> "git pr integrate".
>>
>> If a project is set up to require reviewers, then there must be at least
>> one approved review by someone with a Reviewer role in the project must
>> approve it, but it is the Committer who integrates it after the review
>> is done, and after all other requirements are satisfied (e.g., many
>> groups require a second reviewer, API changes require a CSR, etc).
>>
>> A contributor who is not a Committer, needs to have a sponsoring
>> Committer "/sponsor" their change after they issue the "/integrate"
>> command to indicate that they are ready for it to be pushed.
>>
>> In both cases, it is the Committer who initiates the push.
>>
>> -- Kevin
>>
>>
>> On 11/15/2019 3:22 PM, Mario Torre wrote:
>>> Hi Joe,
>>>
>>> Thanks for sharing this.
>>>
>>> On question still remains however, with the move to a pull request model we
>>> effectively give up the role of a committer (even if we maintain it to
>>> respect the bylaw it would be an empty role), this is because the reviewer
>>> or maintainer that approves the change request of effectively committing
>>> and the original author of the patch may have any of the roles from a
>>> simple contributor to a reviewer.
>>>
>>> Is that true or how else would we be dealing with contributions?
>>>
>>> Cheers,
>>> Mario
>>>
>>> On Fri 15. Nov 2019 at 23:39, Joe Darcy <joe.darcy at oracle.com> wrote:
>>>
>>>> On 11/15/2019 2:22 PM, Mario Torre wrote:
>>>>
>>>> One can argue that git is onerous the same way, the thing is that you are
>>>> not used to mercurial so it appears difficult for you. For this reason I
>>>> may say I won’t contribute a line of code if we switch to git but the
>>>> reality is that if I want or need for some reason I find my way. After all
>>>> we started with Classpath, that was cvs...
>>>>
>>>> All that said, this JEP is only incidentally about git, it’s about GitHub,
>>>> and we shouldn’t confuse the two things.
>>>>
>>>> At the end of the day everyone will still have to go through the governance
>>>> model so it can’t happen that we accept random contributions anymore than
>>>> now, unless this JEP is also about changing the bylaw and giving away with
>>>> the current role system.
>>>>
>>>> The governance model implications are explicitly mentioned in the JEP in
>>>> the goals section:
>>>>
>>>>
>>>>      - Do not change the OpenJDK Bylaws <https://openjdk.java.net/bylaws>.
>>>>      - Do not change the OpenJDK Census <https://openjdk.java.net/census>.
>>>>
>>>> I attended an OpenJDK governing board meeting this October to discuss
>>>> Skara:
>>>>
>>>>          https://openjdk.java.net/groups/gb/minutes/2019-10-10
>>>>
>>>> The slides I presented explicitly quote from the current bylaws:
>>>>
>>>> Section 6 of the OpenJDK Bylaws: "A Project may have web content, one or
>>>> more code repositories, and one or more mailing lists. Projects are
>>>> expected to operate in an open, transparent, and meritocratic manner. Their
>>>> alignment with these principles will be monitored by the Governing Board."
>>>>
>>>> Appendix A of the OpenJDK Bylaws: "The data stored in any infrastructure
>>>> provided for use by Community members must be made available by some means
>>>> that enables, without undue effort, the construction of a complete
>>>> functional clone of that infrastructure and its data as seen by the entire
>>>> Community."
>>>>
>>>> No one present at the meeting disagreed with the assessment that the
>>>> bylaws would *not* need to be updated to use a hosting provider for the
>>>> JDK's sources.
>>>>
>>>>
>>>> -Joe
>>>>
>