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