Re: Repositories, AdoptOpenJDK and github

[Johan Vos]

In my view, the difference between accepting a PR into GitHub versus into
OpenJFX is probably mainly time-based. When there is an agreement about a
PR, it can be merged in GitHub, but there are more steps required (webrev)
before it can formally be pushed into OpenJFX, so the reviewer may choose
to do that later (e.g. and combine a number of PR's).

- Johan

On Sat, Mar 3, 2018 at 7:35 PM Nir Lisker  wrote:

> 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.
>
>
> Doesn't that mean that accepting a fix into GitHub is equivalent to
> accepting it into OpenJFX? In that case there shouldn't be any edge cases.
> The only difference is that the patch delivery system is different. After
> a PR is accepted, the GitHub patch should be converted to an OpenJFX patch.
> Webrev or not webrev seems to me like a tooling issue.
>

> Having a small number of JBS bugs that are low hanging fruit will be good
>> to see how the flow works.
>
>
> I'm still not sure about all the steps. In order to submit a PR I need
> GitHub permissions? Can you know if I signed the OCA?
>
> - Nir
>
>
> On Wed, Feb 28, 2018 at 5:55 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>>
>> > Eugene created an easy one:
>> https://bugs.openjdk.java.net/browse/JDK-8198795
>>
>> I pointed out some prerequisites for doing this in JBS (and Nir expressed
>> concern as well), but yes, this might be a good one to start with.
>>
>> -- Kevin
>>
>>
>> Johan Vos wrote:
>>
>> 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> 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"  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, 20

Re: Repositories, AdoptOpenJDK and github

[Michael Ennen]

In my opinion we need a bot that does a few things to automate the GitHub
to OpenJFX contribution workflow.

One of those things is we can, upon getting a new pull request from someone
we haven't seen before, go over the OCA list and see if a username matches
their Github username. If it does, the bot can comment on the PR with
something
containing:

"This looks like your first contribution to the OpenJFX Github repository.
Have
you signed the OCA (Oracle Contributor Agreement) before with the username
"brcolow" (name: Michael Ennen)? If so, reply with 'Yes, that is me." or if
not
reply with "Nope.".

If we don't find their username in the OCA list we can ask basically the
same question but leave out the bit with asking if they signed under their
github repository.

We will keep track of people that have signed it (and associate their github
account info) so they only need to go through that once.

I have seen this done in other github repositories (I think Microsoft uses
something like this?) but can't think of them off-hand.

Other things the bot will handle should be converting to a mercurial commit,
generating a webrev, associating/asking for a JBS bug report, etc.

I am willing to step up and write this bot. My idea would be to write it in
Java
and use something like AWS Lambda to have it run every X minutes or so.
Alternatives are welcome...especially if there is some existing server
infrastructure we could use.

- Michael Ennen

On Sat, Mar 3, 2018 at 11:49 AM, Michael Paus  wrote:

> Am 03.03.18 um 19:35 schrieb Nir Lisker:
>
>> I'm still not sure about all the steps. In order to submit a PR I need
>> GitHub permissions? Can you know if I signed the OCA?
>>
> There is a publicly available list of people which have signed the OCA
> here:
> http://www.oracle.com/technetwork/community/oca-486395.html
> --Michael
>

Re: Repositories, AdoptOpenJDK and github

[Michael Paus]

Am 03.03.18 um 19:35 schrieb Nir Lisker:

I'm still not sure about all the steps. In order to submit a PR I need
GitHub permissions? Can you know if I signed the OCA?

There is a publicly available list of people which have signed the OCA here:
http://www.oracle.com/technetwork/community/oca-486395.html
--Michael

Re: Repositories, AdoptOpenJDK and github

[Nir Lisker]

>
> 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.


Doesn't that mean that accepting a fix into GitHub is equivalent to
accepting it into OpenJFX? In that case there shouldn't be any edge cases.
The only difference is that the patch delivery system is different. After a
PR is accepted, the GitHub patch should be converted to an OpenJFX patch.
Webrev or not webrev seems to me like a tooling issue.

Having a small number of JBS bugs that are low hanging fruit will be good
> to see how the flow works.


I'm still not sure about all the steps. In order to submit a PR I need
GitHub permissions? Can you know if I signed the OCA?

- Nir


On Wed, Feb 28, 2018 at 5:55 PM, Kevin Rushforth  wrote:

>
> > Eugene created an easy one: https://bugs.openjdk.java.net/
> browse/JDK-8198795
>
> I pointed out some prerequisites for doing this in JBS (and Nir expressed
> concern as well), but yes, this might be a good one to start with.
>
> -- Kevin
>
>
> Johan Vos wrote:
>
> 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 
> 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"  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>
>> 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 mitig

Re: Repositories, AdoptOpenJDK and github

[Kevin Rushforth]

> Eugene created an easy one: 
https://bugs.openjdk.java.net/browse/JDK-8198795


I pointed out some prerequisites for doing this in JBS (and Nir 
expressed concern as well), but yes, this might be a good one to start with.


-- Kevin


Johan Vos wrote:

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 
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" 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
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
> wrote:
>
>> This seems a good start in formalizing the process. It will
need a little
>> tweaking 

Re: Repositories, AdoptOpenJDK and github

[Kevin Rushforth]

Hi Johan,

Your points all make sense to me. In that case, we need to make the 
policy for approving PRs such that it meets the code review criteria 
(which is still something we need to formalize) -- meaning that a 
"Reviewer"  (or more in the case of larger changes) needs to review it 
and not just any "Committer". If we do that, then I there should be no 
cause for rejected reviews, since it will have already been "Reviewed".


-- Kevin


Johan Vos wrote:

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 
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
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


N

Re: Repositories, AdoptOpenJDK and github

[Johan Vos]

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 
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"  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>
> 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> 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 m

Re: Repositories, AdoptOpenJDK and github

[Laurent Bourgès]

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"  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 
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> 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

Re: Repositories, AdoptOpenJDK and github

[Johan Vos]

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 
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> 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 

Re: Repositories, AdoptOpenJDK and github

[Kevin Rushforth]

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 
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
mailto:kevin.rushfo...@oracle.com>>
wrote:



Johan Vos wrote:



On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth
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 wh

Re: Repositories, AdoptOpenJDK and github

[Nir Lisker]

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

Re: Repositories, AdoptOpenJDK and github

[Kevin Rushforth]

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 
mailto:kevin.rushfo...@oracle.com>> wrote:




Johan Vos wrote:



On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth
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/#

Re: Repositories, AdoptOpenJDK and github

[Nir Lisker]

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  wrote:

>
>
> Johan Vos wrote:
>
>
>
> On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth <
> 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
>
>

Re: Repositories, AdoptOpenJDK and github

[Kevin Rushforth]

Johan Vos wrote:



On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth 
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 

Re: Repositories, AdoptOpenJDK and github

[Johan Vos]

On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth 
wrote:

>
> As I said before, we need to be careful where the discussion is made. PRs
> on GitHub have their own thread and there's also the mailing list. Maybe
> someone from Oracle already has done work related to the PR, and this will
> only be known if a JBS issue is submitted or a mailing list thread is
> started. Isn't this supposed to happen before starting to work on a PR even
> (ideally)?
>
>
> Yes, which is why I propose that we start with a JBS bug ID. A note to the
> list along the lines of "Hi, I'd like to work on JDK-123456" would be a
> good idea too, to avoid duplication of effort, and to indicate to other
> developers that the bug is now being looked at.
>

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?

- Johan

Re: Repositories, AdoptOpenJDK and github

[Kevin Rushforth]

As I said before, we need to be careful where the discussion is made. PRs
on GitHub have their own thread and there's also the mailing list. Maybe
someone from Oracle already has done work related to the PR, and this will
only be known if a JBS issue is submitted or a mailing list thread is
started. Isn't this supposed to happen before starting to work on a PR even
(ideally)?


Yes, which is why I propose that we start with a JBS bug ID. A note to 
the list along the lines of "Hi, I'd like to work on JDK-123456" would 
be a good idea too, to avoid duplication of effort, and to indicate to 
other developers that the bug is now being looked at.


-- Kevin




Nir Lisker wrote:

Thank you!

My concerns (not complaints) and questions:

1. Developer forks the github repo, enhances it, and creates a PR.

2. He discusses it with a committer, and eventually the PR is accepted.


As I said before, we need to be careful where the discussion is made. PRs
on GitHub have their own thread and there's also the mailing list. Maybe
someone from Oracle already has done work related to the PR, and this will
only be known if a JBS issue is submitted or a mailing list thread is
started. Isn't this supposed to happen before starting to work on a PR even
(ideally)?

If you want to contribute, you can create PR's. The idea is that OpenJFX
  

committers can merge PR's in this repository.




Are these PRs linked/related in some way to JBS? Currently, one would
submit a JIRA ticket, then work under that roof. Is that something the
committer will do after the PR has been merged?

How would you verify the identity of committers (or contributors for the
purpose of OCA) for GitHub? If I become a committer, I wouldn't want
someone to create an account with my name and ask you to give them
committer rights.

Generally, as a non-committer, is it intended that I'll be able to work
through both Oracle's and GitHub's channels? For one issue I can submit a
PR and have a committer handle the webrev in my name, and for another issue
I can do it myself?

- Nir
  

Re: Repositories, AdoptOpenJDK and github

[Kevin Rushforth]

As far as the bug goes, I think it would be better to do it the other 
way around. If we adopt a policy that a PR should reference a bug in 
JBS, then that part of the problem will go away. I'm not convinced that 
merging a random PR, for what is essentially just "a good idea" if it 
isn't backed by a JBS bug, is all that useful. IBy having a bug in JBS 
before generating the PR, we are that much farther along towards getting 
it integrated.


-- Kevin


Michael Ennen wrote:

Having a bot that creates a webrev, verifies OCA is signed for the commit
author,
and a generates a JBS/java bug report template would be ideal IMO.

We can use something like AWS Lambda that runs every X minutes and checks
for PRs to the openjdk-jfx GitHub repository. If a new PR is seen, or a PR
is updated,
the webrev, OCA confirmation, and bug report template are auto-generated
and the
bot can, for example, post a comment on the PR or we could use the github PR
status check feature.

Just some ideas.

- Michael

On Wed, Feb 14, 2018 at 3:25 PM, Nir Lisker  wrote:

  

Thank you!

My concerns (not complaints) and questions:

1. Developer forks the github repo, enhances it, and creates a PR.

2. He discusses it with a committer, and eventually the PR is accepted.


As I said before, we need to be careful where the discussion is made. PRs
on GitHub have their own thread and there's also the mailing list. Maybe
someone from Oracle already has done work related to the PR, and this will
only be known if a JBS issue is submitted or a mailing list thread is
started. Isn't this supposed to happen before starting to work on a PR even
(ideally)?

If you want to contribute, you can create PR's. The idea is that OpenJFX


committers can merge PR's in this repository.
  

Are these PRs linked/related in some way to JBS? Currently, one would
submit a JIRA ticket, then work under that roof. Is that something the
committer will do after the PR has been merged?

How would you verify the identity of committers (or contributors for the
purpose of OCA) for GitHub? If I become a committer, I wouldn't want
someone to create an account with my name and ask you to give them
committer rights.

Generally, as a non-committer, is it intended that I'll be able to work
through both Oracle's and GitHub's channels? For one issue I can submit a
PR and have a committer handle the webrev in my name, and for another issue
I can do it myself?

- Nir

Re: Repositories, AdoptOpenJDK and github

[Michael Ennen]

Having a bot that creates a webrev, verifies OCA is signed for the commit
author,
and a generates a JBS/java bug report template would be ideal IMO.

We can use something like AWS Lambda that runs every X minutes and checks
for PRs to the openjdk-jfx GitHub repository. If a new PR is seen, or a PR
is updated,
the webrev, OCA confirmation, and bug report template are auto-generated
and the
bot can, for example, post a comment on the PR or we could use the github PR
status check feature.

Just some ideas.

- Michael

On Wed, Feb 14, 2018 at 3:25 PM, Nir Lisker  wrote:

> Thank you!
>
> My concerns (not complaints) and questions:
>
> 1. Developer forks the github repo, enhances it, and creates a PR.
>
> 2. He discusses it with a committer, and eventually the PR is accepted.
>
>
> As I said before, we need to be careful where the discussion is made. PRs
> on GitHub have their own thread and there's also the mailing list. Maybe
> someone from Oracle already has done work related to the PR, and this will
> only be known if a JBS issue is submitted or a mailing list thread is
> started. Isn't this supposed to happen before starting to work on a PR even
> (ideally)?
>
> If you want to contribute, you can create PR's. The idea is that OpenJFX
> > committers can merge PR's in this repository.
>
>
> Are these PRs linked/related in some way to JBS? Currently, one would
> submit a JIRA ticket, then work under that roof. Is that something the
> committer will do after the PR has been merged?
>
> How would you verify the identity of committers (or contributors for the
> purpose of OCA) for GitHub? If I become a committer, I wouldn't want
> someone to create an account with my name and ask you to give them
> committer rights.
>
> Generally, as a non-committer, is it intended that I'll be able to work
> through both Oracle's and GitHub's channels? For one issue I can submit a
> PR and have a committer handle the webrev in my name, and for another issue
> I can do it myself?
>
> - Nir
>

Re: Repositories, AdoptOpenJDK and github

[Nir Lisker]

Thank you!

My concerns (not complaints) and questions:

1. Developer forks the github repo, enhances it, and creates a PR.

2. He discusses it with a committer, and eventually the PR is accepted.


As I said before, we need to be careful where the discussion is made. PRs
on GitHub have their own thread and there's also the mailing list. Maybe
someone from Oracle already has done work related to the PR, and this will
only be known if a JBS issue is submitted or a mailing list thread is
started. Isn't this supposed to happen before starting to work on a PR even
(ideally)?

If you want to contribute, you can create PR's. The idea is that OpenJFX
> committers can merge PR's in this repository.


Are these PRs linked/related in some way to JBS? Currently, one would
submit a JIRA ticket, then work under that roof. Is that something the
committer will do after the PR has been merged?

How would you verify the identity of committers (or contributors for the
purpose of OCA) for GitHub? If I become a committer, I wouldn't want
someone to create an account with my name and ask you to give them
committer rights.

Generally, as a non-committer, is it intended that I'll be able to work
through both Oracle's and GitHub's channels? For one issue I can submit a
PR and have a committer handle the webrev in my name, and for another issue
I can do it myself?

- Nir

Re: Repositories, AdoptOpenJDK and github

[Johan Vos]

Hi Michael,

That is great!
Using Travis CI will clearly help keeping the project in a good shape.

I added a comment, and I hope others with more experience with Travis than
me will jump in.

Thanks,

- Johan

On Wed, Feb 14, 2018 at 9:21 PM Michael Ennen  wrote:

> Thanks for taking the initiative, Johan.
>
> I have opened two PRs that add support for Travis CI and Appveyor
> continuous integration (which can be used to build pull requests and
> the master branch after a merge (or using a cron-timer) automatically).
>
> This will allow sandboxers to test their code on all 3 major supported
> platforms: Linux, macOS, and Windows.
>
> Regards,
> Michael
>
> On Wed, Feb 14, 2018 at 8:14 AM, Johan Vos  wrote:
>
>> Hi,
>>
>> I did 2 things:
>> * I talked to the fine and great people at AdoptOpenJDK (
>> https://adoptopenjdk.net/) and they are happy to have their build farm
>> being used to create OpenJFX modules (including the native libraries). We
>> are currently looking at the scripts that are being used for syncing and
>> building OpenJDK, and the sync script is already in place.
>>
>> * While on the subject of syncing, I used a similar script to create and
>> sync a mirror of OpenJFX at github. It is now available at
>> https://github.com//javafxports/openjdk-jfx
>> (planning to sync at least a few times a day, by pulling in the latest
>> changes from OpenJFX).
>>
>> This is a sandbox repository, and it won't be used to automatically
>> generate builds from.
>> If you want to play with the source, add features, fix bugs, work on
>> documentation, you can fork this repository. If you want to contribute,
>> you
>> can create PR's. The idea is that OpenJFX committers can merge PR's in
>> this
>> repository. That doesn't automatically upstream them to OpenJFX, but if an
>> OpenJFX committer agrees with your PR, he can use the existing webrev
>> system at OpenJFX to start the process of merging it into OpenJFX.
>> Since a PR might be used to merge code in OpenJFX, it is required that you
>> have an OCA (see
>> http://www.oracle.com/technetwork/community/oca-486395.html for
>> more info).
>>
>> In summary, the flow might look like this:
>> 1. Developer forks the github repo, enhances it, and creates a PR.
>> 2. He discusses it with a committer, and eventually the PR is accepted.
>> 3. The committer creates a webrev and an OpenJFX Reviewer reviews.
>> 4. If accepted, that code is merged into OpenJFX.
>> 5. The AdoptOpenJFX build farm creates a build including that new code.
>>
>> Note that this creates additional work for the current OpenJFX committers
>> (including myself). Please be patient and helpful if you raise a PR. I
>> expect PR's to be well tested and documented. A PR is not just an idea
>> with
>> some code being thrown over the wall.
>>
>> JavaFX has been Open Source for a very long time. By having the code also
>> as a github mirror, I hope we can attract more people, and get more
>> attention to this great project, while preserving the high quality that is
>> really needed to keep JavaFX aligned with the high standards that people
>> expect from the Java platform.
>>
>> Thanks,
>>
>> - Johan
>>
>
>

Re: Repositories, AdoptOpenJDK and github

[Michael Ennen]

Thanks for taking the initiative, Johan.

I have opened two PRs that add support for Travis CI and Appveyor
continuous integration (which can be used to build pull requests and
the master branch after a merge (or using a cron-timer) automatically).

This will allow sandboxers to test their code on all 3 major supported
platforms: Linux, macOS, and Windows.

Regards,
Michael

On Wed, Feb 14, 2018 at 8:14 AM, Johan Vos  wrote:

> Hi,
>
> I did 2 things:
> * I talked to the fine and great people at AdoptOpenJDK (
> https://adoptopenjdk.net/) and they are happy to have their build farm
> being used to create OpenJFX modules (including the native libraries). We
> are currently looking at the scripts that are being used for syncing and
> building OpenJDK, and the sync script is already in place.
>
> * While on the subject of syncing, I used a similar script to create and
> sync a mirror of OpenJFX at github. It is now available at
> https://github.com//javafxports/openjdk-jfx
> (planning to sync at least a few times a day, by pulling in the latest
> changes from OpenJFX).
>
> This is a sandbox repository, and it won't be used to automatically
> generate builds from.
> If you want to play with the source, add features, fix bugs, work on
> documentation, you can fork this repository. If you want to contribute, you
> can create PR's. The idea is that OpenJFX committers can merge PR's in this
> repository. That doesn't automatically upstream them to OpenJFX, but if an
> OpenJFX committer agrees with your PR, he can use the existing webrev
> system at OpenJFX to start the process of merging it into OpenJFX.
> Since a PR might be used to merge code in OpenJFX, it is required that you
> have an OCA (see
> http://www.oracle.com/technetwork/community/oca-486395.html for
> more info).
>
> In summary, the flow might look like this:
> 1. Developer forks the github repo, enhances it, and creates a PR.
> 2. He discusses it with a committer, and eventually the PR is accepted.
> 3. The committer creates a webrev and an OpenJFX Reviewer reviews.
> 4. If accepted, that code is merged into OpenJFX.
> 5. The AdoptOpenJFX build farm creates a build including that new code.
>
> Note that this creates additional work for the current OpenJFX committers
> (including myself). Please be patient and helpful if you raise a PR. I
> expect PR's to be well tested and documented. A PR is not just an idea with
> some code being thrown over the wall.
>
> JavaFX has been Open Source for a very long time. By having the code also
> as a github mirror, I hope we can attract more people, and get more
> attention to this great project, while preserving the high quality that is
> really needed to keep JavaFX aligned with the high standards that people
> expect from the Java platform.
>
> Thanks,
>
> - Johan
>

Re: Repositories, AdoptOpenJDK and github

[han . solo]

Johan,

Thank‘s so much for all the effort you‘ve put into OpenJFX...it is highly 
appreciated 👍🏻

Keep up the great work,

Cheers,

Gerrit

Gerrit Grunwald
Westfalenstr. 93
48165 Münster
Germany

tel: +49 (0)2501 24321
mob: +49 (0)171 1745350
web: http://www.harmonic-code.org


Am 14. Feb. 2018, 16:14 +0100 schrieb Johan Vos :
> Hi,
>
> I did 2 things:
> * I talked to the fine and great people at AdoptOpenJDK (
> https://adoptopenjdk.net/) and they are happy to have their build farm
> being used to create OpenJFX modules (including the native libraries). We
> are currently looking at the scripts that are being used for syncing and
> building OpenJDK, and the sync script is already in place.
>
> * While on the subject of syncing, I used a similar script to create and
> sync a mirror of OpenJFX at github. It is now available at
> https://github.com//javafxports/openjdk-jfx
> (planning to sync at least a few times a day, by pulling in the latest
> changes from OpenJFX).
>
> This is a sandbox repository, and it won't be used to automatically
> generate builds from.
> If you want to play with the source, add features, fix bugs, work on
> documentation, you can fork this repository. If you want to contribute, you
> can create PR's. The idea is that OpenJFX committers can merge PR's in this
> repository. That doesn't automatically upstream them to OpenJFX, but if an
> OpenJFX committer agrees with your PR, he can use the existing webrev
> system at OpenJFX to start the process of merging it into OpenJFX.
> Since a PR might be used to merge code in OpenJFX, it is required that you
> have an OCA (see
> http://www.oracle.com/technetwork/community/oca-486395.html for
> more info).
>
> In summary, the flow might look like this:
> 1. Developer forks the github repo, enhances it, and creates a PR.
> 2. He discusses it with a committer, and eventually the PR is accepted.
> 3. The committer creates a webrev and an OpenJFX Reviewer reviews.
> 4. If accepted, that code is merged into OpenJFX.
> 5. The AdoptOpenJFX build farm creates a build including that new code.
>
> Note that this creates additional work for the current OpenJFX committers
> (including myself). Please be patient and helpful if you raise a PR. I
> expect PR's to be well tested and documented. A PR is not just an idea with
> some code being thrown over the wall.
>
> JavaFX has been Open Source for a very long time. By having the code also
> as a github mirror, I hope we can attract more people, and get more
> attention to this great project, while preserving the high quality that is
> really needed to keep JavaFX aligned with the high standards that people
> expect from the Java platform.
>
> Thanks,
>
> - Johan

Re: Repositories, AdoptOpenJDK and github

[Kevin Rushforth]

Nice! Thanks for your hard work on this, Johan.

-- Kevin


Johan Vos wrote:

Hi,

I did 2 things:
* I talked to the fine and great people at AdoptOpenJDK (
https://adoptopenjdk.net/) and they are happy to have their build farm
being used to create OpenJFX modules (including the native libraries). We
are currently looking at the scripts that are being used for syncing and
building OpenJDK, and the sync script is already in place.

* While on the subject of syncing, I used a similar script to create and
sync a mirror of OpenJFX at github. It is now available at
https://github.com//javafxports/openjdk-jfx
(planning to sync at least a few times a day, by pulling in the latest
changes from OpenJFX).

This is a sandbox repository, and it won't be used to automatically
generate builds from.
If you want to play with the source, add features, fix bugs, work on
documentation, you can fork this repository. If you want to contribute, you
can create PR's. The idea is that OpenJFX committers can merge PR's in this
repository. That doesn't automatically upstream them to OpenJFX, but if an
OpenJFX committer agrees with your PR, he can use the existing webrev
system at OpenJFX to start the process of merging it into OpenJFX.
Since a PR might be used to merge code in OpenJFX, it is required that you
have an OCA (see
http://www.oracle.com/technetwork/community/oca-486395.html for
more info).

In summary, the flow might look like this:
1. Developer forks the github repo, enhances it, and creates a PR.
2. He discusses it with a committer, and eventually the PR is accepted.
3. The committer creates a webrev and an OpenJFX Reviewer reviews.
4. If accepted, that code is merged into OpenJFX.
5. The AdoptOpenJFX build farm creates a build including that new code.

Note that this creates additional work for the current OpenJFX committers
(including myself). Please be patient and helpful if you raise a PR. I
expect PR's to be well tested and documented. A PR is not just an idea with
some code being thrown over the wall.

JavaFX has been Open Source for a very long time. By having the code also
as a github mirror, I hope we can attract more people, and get more
attention to this great project, while preserving the high quality that is
really needed to keep JavaFX aligned with the high standards that people
expect from the Java platform.

Thanks,

- Johan
  

Repositories, AdoptOpenJDK and github

[Johan Vos]

Hi,

I did 2 things:
* I talked to the fine and great people at AdoptOpenJDK (
https://adoptopenjdk.net/) and they are happy to have their build farm
being used to create OpenJFX modules (including the native libraries). We
are currently looking at the scripts that are being used for syncing and
building OpenJDK, and the sync script is already in place.

* While on the subject of syncing, I used a similar script to create and
sync a mirror of OpenJFX at github. It is now available at
https://github.com//javafxports/openjdk-jfx
(planning to sync at least a few times a day, by pulling in the latest
changes from OpenJFX).

This is a sandbox repository, and it won't be used to automatically
generate builds from.
If you want to play with the source, add features, fix bugs, work on
documentation, you can fork this repository. If you want to contribute, you
can create PR's. The idea is that OpenJFX committers can merge PR's in this
repository. That doesn't automatically upstream them to OpenJFX, but if an
OpenJFX committer agrees with your PR, he can use the existing webrev
system at OpenJFX to start the process of merging it into OpenJFX.
Since a PR might be used to merge code in OpenJFX, it is required that you
have an OCA (see
http://www.oracle.com/technetwork/community/oca-486395.html for
more info).

In summary, the flow might look like this:
1. Developer forks the github repo, enhances it, and creates a PR.
2. He discusses it with a committer, and eventually the PR is accepted.
3. The committer creates a webrev and an OpenJFX Reviewer reviews.
4. If accepted, that code is merged into OpenJFX.
5. The AdoptOpenJFX build farm creates a build including that new code.

Note that this creates additional work for the current OpenJFX committers
(including myself). Please be patient and helpful if you raise a PR. I
expect PR's to be well tested and documented. A PR is not just an idea with
some code being thrown over the wall.

JavaFX has been Open Source for a very long time. By having the code also
as a github mirror, I hope we can attract more people, and get more
attention to this great project, while preserving the high quality that is
really needed to keep JavaFX aligned with the high standards that people
expect from the Java platform.

Thanks,

- Johan