I agree with this approach.
Having a small number of JBS bugs that are low hanging fruit will be
good to see how the flow works.
Eugene created an easy one:
https://bugs.openjdk.java.net/browse/JDK-8198795
- Johan
On Wed, Feb 28, 2018 at 9:52 AM Laurent Bourgès
<bourges.laur...@gmail.com <mailto:bourges.laur...@gmail.com>> wrote:
Johan,
I am following the long discussion and I mostly agree what was said.
Maybe it is time to start working on github on few minor / trivial
bugs... to test all the new process.
I propose to extract few JBS bugs (small) with high ROI (agile
/scrum approach) and create shadow copies into github issues (id,
title, short description & JBS LINK) to be proposed to the jfx
community.
That would become our backlog that can be managed in a kanban
board (github project). Moreover it would be awesome if such board
would gather the activity of both oracle & community people on
OpenJFX.
Once somebody wants to work on one issue, just comment on the
github issue and start working in your fork, make PR...
Adopting this method, anybody will know publicly what's going on
and it would reduce the risk of conflicts (code merge)....
My 2 cents...
Let's go on,
"We are the champions..."
Laurent
Le 28 févr. 2018 9:15 AM, "Johan Vos" <johan....@gluonhq.com
<mailto:johan....@gluonhq.com>> a écrit :
That is the difficult point indeed.
But why would a PR to OpenJFX be rejected after it was
approved in the
github mirror? I would assume the main reason for this is
because the PR
did not what it was supposed to do. In that case, it makes
sense to remove
the commits from the github mirror as well.
I think the main thing here is that we need to be very serious
about
reviewing and accepting PR's in the github mirror. Accepting a
PR in github
does not require the *formal* process of creating webrevs etc,
but it
requires discussion about the issue with reviewers of OpenJFX.
We have to minimize the number of times an edge case occurs,
in which the
discussion was pro PR first, but after it got merged into
"development" new
arguments are brought up against the PR.
I think it would be good to have sort of a post-mortem
analysis in case
this happens, in order to prevent it from happening again. But
as I said,
if it does happen, it probably has good reasons and in that
case we have to
remove it from the development branch as well.
I think the more common case would be that an issue is fixed
on the github
mirror, but not yet accepted (nor rejected) in OpenJFX, so
there will be
some time lag between the PR acceptance and the integration in
OpenJFX. But
this should not be a problem, as long as the following
scenario is the main
flow:
The github master branch is always synced with OpenJFX, and
never gets
modified by other commits.
The github "development" branch is where we accept PR's, that
can then be
send upstream. Changes from "master" are regularly merged into
"development". The moment an accepted PR makes it into
OpenJFX, it will be
synced into "master" and merged into "development" where the
merge happens
silently as there are no conflicts (since development already
has this
code).
Does that make sense?
- Johan
On Wed, Feb 28, 2018 at 12:51 AM Kevin Rushforth
<kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>>
wrote:
>
>
> Nir Lisker wrote:
>
> 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?
>
>
> Good questions; maybe Johan has some thoughts as to how to
mitigate this?
>
>
> -- Kevin
>
>
>
> 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
>>>
>>>
>>
>
