On Wed, Feb 28, 2018 at 12:25 AM, Kevin Rushforth
<kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>>
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.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
- Johan
