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.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>> wrote:
Johan Vos wrote:
On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth
<kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@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
