New candidate JEP: 369: Migrate to GitHub

Kevin Rushforth kevin.rushforth at oracle.com
Fri Nov 15 23:34:26 UTC 2019


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
>>



More information about the discuss mailing list