New candidate JEP: 369: Migrate to GitHub

Eric Vergnaud eric.vergnaud at wanadoo.fr
Sun Nov 24 02:53:50 UTC 2019


Not advertising anything, there are all sorts of tools out there, to suit your personal taste.
I personally use Source Tree, so I only rarely visit GitHub, and almost never use cmd line git.

> Le 22 nov. 2019 à 22:44, Kevin Rushforth <kevin.rushforth at oracle.com> a écrit :
> 
> 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
>>>>> 
>> 
> 



More information about the discuss mailing list