Repositories, AdoptOpenJDK and github

Nir Lisker nlisker at
Tue Feb 27 23:38:47 UTC 2018

> Johan's thinking was to allow Committers to approve the PR on GitHub --
> meaning they could be merged on GitHub before an actual Review has
> happened. Are you proposing to change that?

What if the PR is rejected at review? We'll end up with conflicts between
the repos. And supposed someone works on a different fix and uses the
rejected PR code, how will that be committed?

On Wed, Feb 28, 2018 at 12:25 AM, Kevin Rushforth <
kevin.rushforth at> wrote:

> This seems a good start in formalizing the process. It will need a little
> tweaking in a couple of areas.
> Regarding JBS access, even though I want to relax the requirement to
> become an Author (get a JBS account), it will likely end up somewhere
> between "an intention to contribute" and "two sponsored contributions,
> already reviewed and committed". Even without this, there will necessarily
> be a gap in time between "I want to work on a bug" and getting a JBS
> account. So there is value in encouraging people to clone the GitHub
> sandbox, "kick the tires", make a PR to get feedback, etc., before they can
> access JBS directly (or even while waiting for their OCA to be processed,
> but no PRs in that case). Something to take into account.
> Regarding review, we will need a bit more discussion on that. I like the
> idea of the PR being logged in JBS once it is ready to be reviewed. Johan's
> thinking was to allow Committers to approve the PR on GitHub -- meaning
> they could be merged on GitHub before an actual Review has happened. Are
> you proposing to change that? It might have some advantages, but it could
> also make it harder in other areas. I'd like to hear from Johan on this.
> This reminds me that we need to continue the discussion on the general
> "Review" policy, as it is relevant here.
> As for whether it is merged into GitHub, I don't have a strong opinion on
> that. As you say it will be pulled into the mirror anyway (along with
> changes from reviews happening in JBS that don't first go through the
> sandbox), so maybe it doesn't matter? On the other hand there might be
> advantages to getting it into the mainline of the sandbox early? Hard to
> say.
> -- Kevin
> Nir Lisker wrote:
> Iv'e given the pipeline some thought. I'm purposely ignoring current role
> names (Author, Contributor...). My suggestions:
> Potential contributor wants to contribute...
> 1. Formal process
>   a. If the issue is not in the JBS, they submit it via bugreport.
>   b. They send an email on the mailing list regarding the issue (a plan,
> question on how to approach etc.)
>   c. If the above effort is "deemed worthy" (whatever that means), and
> they have signed the OCA, and they then they get access to JBS. If they've
> given a GitHub account, they get access to GitHub PRs.
>   d. Discussion from the mailing list is copied/linked to the JBS issue.
> Maybe if it's their issue (step a) then the Reporter field can change to
> them.
> This ensures that:
> * There's 1 entry point.
> * GitHub and JBS identities are linked (GitHub identity is verified).
> * Being able to comment on JBS is easier - instead of requiring 2 commits
> it requires good intentions(?)
> * Not every person on the planet has access to JBS.
> 2. Work process
>   a. They fork the GitHub repo.
>   b. They create a PR with a 2-way link to/from JBS (similar to  current
> webrevs - JBS links).
>   c. Discussion specifically on the patch should happen in the PR thread.
> General info on the bug (affected versions etc.) still happens in JBS.
>   d. After the patch had been reviewed, it is committed to the Oracle
> repo. Since GitHub mirrors Oracle I don't think it matters if the patch is
> merged into GitHub.
> This ensures that:
> * It's easier to start working because the GiutHub repo is more convenient
> than the Oracle repo currently.
> * PRs and JBS issues are mutually aware.
> * The submit -> review -> commit process is streamlined.
> We pay a synchronization price for having 2 repos and 2 bug trackers. This
> is what I could come up with.
> - Nir
> On Fri, Feb 16, 2018 at 1:14 AM, Kevin Rushforth <
> kevin.rushforth at> wrote:
>> Johan Vos wrote:
>> On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth <
>> kevin.rushforth at> wrote:
>> A global reference in JBS would indeed be very good to track back the
>> work in a PR to a real issue. It can also be very useful as there are many
>> existing issues in JBS that can be referred to in future work.
>> The only issue I see is that in order to create an issue in JBS, you need
>> to have "author" status, so not everyone can do this? Given the idea that
>> developers who want to create a PR also need to sign an OCA, it might make
>> sense to somehow combine the administration?
>> I don't think we can combine this, but I hope to be able to relax the
>> requirements to become an Author a little. The current guidelines are 2
>> sponsored contributions [1].
>> Pending appointment as an Author, it isn't hard to submit a bug via
>> . If there is a test case, it usually gets
>> moved to the JDK project within a day or so (and I can move them sooner, if
>> needed). The bigger bother is that you can't comment in JBS on a bug you
>> didn't create, but once the bug is there, you can work on it in GutHub
>> and/or send email to the list. I'll also add any comments from contributors
>> who are not yet Authors to any bug report.
>> -- Kevin
>> [1]
>> - Johan

More information about the openjfx-dev mailing list