Repositories, AdoptOpenJDK and github
Kevin Rushforth
kevin.rushforth at oracle.com
Tue Feb 27 23:51:39 UTC 2018
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.rushforth at oracle.com <mailto:kevin.rushforth at 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.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>
>> wrote:
>>
>>
>>
>> Johan Vos wrote:
>>>
>>>
>>> On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth
>>> <kevin.rushforth at oracle.com
>>> <mailto:kevin.rushforth at oracle.com>> wrote:
>>>
>>> A global reference in JBS would indeed be very good to track
>>> back the work in a PR to a real issue. It can also be very
>>> useful as there are many existing issues in JBS that can be
>>> referred to in future work.
>>>
>>> The only issue I see is that in order to create an issue in
>>> JBS, you need to have "author" status, so not everyone can
>>> do this? Given the idea that developers who want to create a
>>> PR also need to sign an OCA, it might make sense to somehow
>>> combine the administration?
>>
>> I don't think we can combine this, but I hope to be able to
>> relax the requirements to become an Author a little. The
>> current guidelines are 2 sponsored contributions [1].
>>
>> Pending appointment as an Author, it isn't hard to submit a
>> bug via http://bugreport.java.com/ . If there is a test case,
>> it usually gets moved to the JDK project within a day or so
>> (and I can move them sooner, if needed). The bigger bother is
>> that you can't comment in JBS on a bug you didn't create, but
>> once the bug is there, you can work on it in GutHub and/or
>> send email to the list. I'll also add any comments from
>> contributors who are not yet Authors to any bug report.
>>
>> -- Kevin
>>
>> [1] http://openjdk.java.net/projects/#project-author
>> <http://openjdk.java.net/projects/#project-author>
>>
>>
>>> - Johan
>>
>>
>
More information about the openjfx-dev
mailing list