New candidate JEP: 369: Migrate to GitHub
neugens at redhat.com
Fri Nov 22 13:20:42 UTC 2019
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:
git clone directly-upstream-openjdk
do some work && create webrev && send email request && get approval
Or will I be forced to use the public fork and send PRs?
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
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898
More information about the discuss