Repositories, AdoptOpenJDK and github

Kevin Rushforth kevin.rushforth at oracle.com
Tue Feb 27 22:25:45 UTC 2018


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 oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>
>
>
>     Johan Vos wrote:
>>
>>
>>     On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth
>>     <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>
>>     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 http://bugreport.java.com/ . 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] http://openjdk.java.net/projects/#project-author
>     <http://openjdk.java.net/projects/#project-author>
>
>
>>     - Johan 
>
>


More information about the openjfx-dev mailing list