Another thing to be careful about with the sandbox/staging idea is the confusion that will arise with duplication. There will be 2 issue trackers (JBS and GitHub (or GitHub-like)), 2 repo addresses, 2 wikis, and maybe 2 discussion lists. For those "in the know" this will be a simple matter, but for a potential contributor this can be a gamebreaker if not handled appropriately.
Dalibor Topic's suggestion of contacting other mirrors can be instrumental in solving these problems. - Nir On Mon, Feb 5, 2018 at 4:41 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote: > Yes, this sounds like a good step in the right direction. This would give > anyone (with a signed OCA) the ability to create their own branch, commit > changes to it, submit a PR, etc. > > I presume there will be a branch that is an exact mirror of the jfx-dev > repo on OpenJDK in addition to the development branch in the sandbox? > > The only thing to consider is whether it should be Committers or Reviewers > that have rights to merge into the sandbox development branch. There are > pros / cons of each. I'd probably lean towards having it be Committers, > with the idea that a Committer needs to sponsor the patch anyway and would > then be able to "take it the rest of the way". The only downside I see is > that you could end up with a few patches that get accepted into the sandbox > dev branch, but never make it to the upstream jfx-dev repo (or not without > significant change). I doubt this will be a big problem in practice. > > Either way, this could also provide a good alternative to webrev when > reviewing the final changes. > > -- Kevin > > > > Johan Vos wrote: > >> Hi Michael, >> >> This proposal is very much in line with my thinking as well. >> The problem is not that we don't have a github clone of OpenJFX. We have a >> number of them (e.g. I created https://github.com/javafxports/jfx-dev >> some >> months ago). We just need a single one that is updated constantly from >> mainstream, and standardize on that. Let's call that "sandbox" (I would be >> ok with staging as well, but sandbox is imho more inviting to people who >> want to try something drastic, e.g. support for Vulkan) >> >> The main issue is how to get contributions, review them, and eventually >> send them upstream. >> >> The PR review process is extremely important. If we lower that bar, we >> loose quality. If the bar is too high, great PR's won't be accepted >> upstream as there is not enough review time to review it. >> >> I agree giving the current OpenJFX committers merge rights for the >> "sandbox" repository makes sense. Once a public contribution is merged by >> one of those committers, that same committer can send it upstream to the >> existing OpenJFX repository. Additional checks will be performed there, >> mainly in order to make sure the overall "Feel of Java" is preserved. To >> that purpose, it would help to have a closer alignment with the OpenJDK >> community. >> >> We have to be aware that this will increase the workload of the current >> committers and reviewers. That is the price we pay for standardization. >> Rather than everyone creating his own forks of a UI framework in Java, we >> invest a lot in creating a single, generally agreed one. >> >> So in summary, I'm +1 on a 2-phase approach: "open" commits allowed in >> staging. OpenJFX committers accept PR's (if they are of good quality) and >> prepare upstream commits for OpenJFX. We hope there will be more >> contributors who become committers and reviewers in the medium term. >> >> - Johan >> >> On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen <mike.en...@gmail.com> >> wrote: >> >> >> >>> Those are great questions, and I think with Kevin/Oracle/other OpenJFX >>> devs >>> help we >>> can figure something out. >>> >>> My thinking is that the PR would be reviewed by basically anyone who has >>> free time. >>> I think that, at first, only OpenJFX committers will be able to merge >>> PRs. >>> They would >>> do the final review/merge to the staging repo after it has been reviewed >>> by >>> the "wider audience" >>> which includes people without commit rights (people like us). Then, as >>> this >>> thing evolves, >>> based on the pool of people who are contributing both pull requests and >>> PR >>> reviews, >>> the committers will be able to grant commit privileges to some people in >>> that pool. >>> >>> I can't think of any way that would make it so the changes are as likely >>> to >>> be >>> merged upstream as possible other than having the current OpenJFX >>> committers paving the >>> way. Hopefully this vision is aligned with Kevin's and hopefully these >>> concrete details >>> can be worked out. >>> >>> Regards, >>> Michael >>> >>> On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker <nlis...@gmail.com> wrote: >>> >>> >>> >>>> So if a community ran GitHub is used for staging, who will approve PRs >>>> >>>> >>> for >>> >>> >>>> the code and the Wiki of the GitHub repo? >>>> >>>> On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen <mike.en...@gmail.com> >>>> wrote: >>>> >>>> >>>> >>>>> Great points, Nir. We share the same hopes. I just wanted to piggy-back >>>>> on the >>>>> wiki thing: >>>>> >>>>> " * The Wiki could be open sourced as well (like other Wikis). I could >>>>> definitely update a page or 2 there and so would other developers as >>>>> >>>>> >>>> they >>> >>> >>>> gain knowledge. I don't know yet how permissions for that should be >>>>> handled." >>>>> >>>>> This is another thing that we could use the GitHub staging repository >>>>> >>>>> >>>> for. >>> >>> >>>> The staging repository could have a wiki (projects on GitHub can have >>>>> >>>>> >>>> one) >>> >>> >>>> that is editable by all, and then maybe once a month or so someone with >>>>> permissions >>>>> to edit to official wiki can sync with the new, reviewed changes (the >>>>> once-a-month >>>>> time constraint is very flexible). >>>>> >>>>> I am just trying to explain how the GitHub repository "one-way mirror" >>>>> (potentially linked >>>>> with/managed by Adopt an OpenJDK) can act as a staging ground for all >>>>> kinds of contributions to >>>>> OpenJFX. >>>>> >>>>> By the way, I am trying to cleanup the groundwork I did on getting >>>>> Appveyor builds to >>>>> run for openjfx, if indeed it is decided to setup such a staging >>>>> repository. You can >>>>> see my efforts here: https://raw.githubusercontent. >>>>> >>>>> >>>>> >>>> com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057 >>> /appveyor.yml >>> >>> >>>> If the GitHub repository was setup, changes such as these to add CI >>>>> infrastructure would >>>>> never be adopted by upstream OpenJFX, but would allow for developer's >>>>> to >>>>> get good >>>>> feedback on test results for all supported platforms when they open a >>>>> >>>>> >>>> PR. >>> >>> >>>> Merging a PR >>>>> on the public GitHub repository means, in my opinion, that it is ready >>>>> >>>>> >>>> to >>> >>> >>>> be opened as >>>>> an upstream bug/feature request. Automating the process with patch >>>>> sets, >>>>> webrevs, formatting/lint >>>>> results, etc. would be the most ideal situation and I would be happy to >>>>> contribute to these >>>>> efforts. >>>>> >>>>> Regards, >>>>> >>>>> Michael Ennen >>>>> >>>>> >>>>> >>>>> On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker <nlis...@gmail.com> wrote: >>>>> >>>>> >>>>> >>>>>> Hello, >>>>>> >>>>>> As someone who has recently made the climb and managed to build >>>>>> OpenJFX >>>>>> with OpenJDK on Win 10 I might have some relevant input. >>>>>> >>>>>> --- Building OpenJFX --- >>>>>> >>>>>> * With the recently updated instructions on the Wiki, building OpenJFX >>>>>> >>>>>> >>>>> is >>> >>> >>>> not that hard. Having to build OpenJDK for that was a real headache >>>>>> because >>>>>> their instructions and build tools are not up to date ( >>>>>> https://bugs.openjdk.java.net/browse/JDK-8194645). >>>>>> * The above doesn't mean that the process shouldn't be made easier. >>>>>> Ideally, it would be the as easy as working on most open source >>>>>> >>>>>> >>>>> projects >>> >>> >>>> on >>>>>> Github (not advocating git over hg): clone into the IDE and start >>>>>> working; >>>>>> when a fix is ready, submit a PR. Don't know if it's technically >>>>>> >>>>>> >>>>> possible >>> >>> >>>> in this case, but it's a target. >>>>>> * The repository needs a good cleanup before contributors start >>>>>> >>>>>> >>>>> cloning ( >>> >>> >>>> bugs.openjdk.java.net/browse/JDK-8196198). >>>>>> >>>>>> --- Working on OpenJFX --- >>>>>> >>>>>> * It should be clear which tests need to run for a specific patch. >>>>>> Changes >>>>>> can be made anywhere from the documentation level to native code level >>>>>> and >>>>>> there's no reason to run the same tests for all of these. If the >>>>>> >>>>>> >>>>> process >>> >>> >>>> can be automate it's even better. >>>>>> * The Webrev tool seems archaic to me (and part of its output is >>>>>> broken >>>>>> as >>>>>> far as I could tell). An IDE can create diff patches with a couple of >>>>>> clicks. >>>>>> * The Jcheck tool seems archaic to me. It should be ported to IDE >>>>>> formatters which are to be distributed with the source. No reason to >>>>>> >>>>>> >>>>> run >>> >>> >>>> a >>>>>> tool that tells me which whitespaces I need to go back and change when >>>>>> something like Ctrl+Shift+F in an IDE finishes the job. >>>>>> >>>>>> --- Wiki --- >>>>>> >>>>>> * The Wiki could be open sourced as well (like other Wikis). I could >>>>>> definitely update a page or 2 there and so would other developers as >>>>>> >>>>>> >>>>> they >>> >>> >>>> gain knowledge. I don't know yet how permissions for that should be >>>>>> handled. >>>>>> * Code conventions should be clearly listed. >>>>>> * Separate sections with instructions should be made for: (1) cloning >>>>>> >>>>>> >>>>> and >>> >>> >>>> building, (2) modifying, (3) running tests, (4) submitting, and (5) >>>>>> reviewing. >>>>>> * Old sections should be cleaned up (I don't think Discussions is >>>>>> >>>>>> >>>>> useful >>> >>> >>>> anymore). >>>>>> >>>>>> --- Review policy --- >>>>>> >>>>>> * I have no experience with review policies or project roles so I >>>>>> can't >>>>>> help here much (maybe after a discussion starts). >>>>>> * One thing I do know is that reviewers should be extremely >>>>>> knowledgeable, >>>>>> which means that there aren't many qualified. Because of this, if it >>>>>> becomes "too" easy to contribute to OpenJFX, careful measures need to >>>>>> >>>>>> >>>>> be >>> >>> >>>> taken as to not to swamp the few reviewers with many patches (though >>>>>> >>>>>> >>>>> some >>> >>> >>>> would say this is an ideal situation). Some sort of review queue might >>>>>> help >>>>>> with organization instead of the current email system. I have no >>>>>> >>>>>> >>>>> concrete >>> >>> >>>> solution for this. >>>>>> >>>>>> - Nir >>>>>> >>>>>> >>>>>> Message: 1 >>>>>> >>>>>> >>>>>>> Date: Thu, 01 Feb 2018 15:26:24 -0800 >>>>>>> From: Kevin Rushforth <kevin.rushfo...@oracle.com> >>>>>>> To: "openjfx-dev@openjdk.java.net" <openjfx-dev@openjdk.java.net> >>>>>>> Subject: More community participation in JavaFX >>>>>>> Message-ID: <5a73a220.7030...@oracle.com> >>>>>>> Content-Type: text/plain; charset=windows-1252; format=flowed >>>>>>> >>>>>>> To: OpenJFX Developers >>>>>>> >>>>>>> We are looking to grow the community of contributors to the OpenJFX >>>>>>> project, especially serious contributors who will stick around long >>>>>>> enough to become reviewers, to help us keep the platform vibrant. To >>>>>>> this end we are looking at ways to encourage more participation and >>>>>>> >>>>>>> >>>>>> make >>>>>> >>>>>> >>>>>>> it easier for interested folks to contribute. >>>>>>> >>>>>>> We are specifically looking to discuss ideas around the following >>>>>>> >>>>>>> >>>>>> areas: >>>>>> >>>>>> >>>>>>> * Easing barriers to contribution (e.g., making JavaFX easier to >>>>>>> >>>>>>> >>>>>> build, >>> >>> >>>> better documentation, making it easier to test changes) >>>>>>> >>>>>>> * Code review policies >>>>>>> >>>>>>> * API / feature review policies >>>>>>> >>>>>>> * Code review tools (we currently use webrev, but that isn't set in >>>>>>> >>>>>>> >>>>>> stone) >>>>>> >>>>>> >>>>>>> To keep this thread productive, the following are explicitly out of >>>>>>> >>>>>>> >>>>>> scope: >>>>>> >>>>>> >>>>>>> * Discussion of specific features or bugs that you would like to >>>>>>> implement (or wish someone else would) >>>>>>> >>>>>>> * Discussion about platform support >>>>>>> >>>>>>> * Discussion about version control systems (e.g., hg versus git), >>>>>>> hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus >>>>>>> github), etc...at least for now. We are aware of the potential >>>>>>> >>>>>>> >>>>>> benefits >>> >>> >>>> of such changes, but we'd like to focus our efforts on >>>>>>> >>>>>>> >>>>>> higher-leverage >>> >>> >>>> things we can do in the short term. >>>>>>> >>>>>>> * Discussion about the requirement of a signed OCA to become a >>>>>>> >>>>>>> >>>>>> contributor >>>>>> >>>>>> >>>>>>> * Off-topic or tangential commentary about OpenJFX that isn't >>>>>>> >>>>>>> >>>>>> directly >>> >>> >>>> related to the topic at hand >>>>>>> >>>>>>> >>>>>>> As a starting point for discussion, here are some areas I think need >>>>>>> improvement; I'm sure there are others: >>>>>>> >>>>>>> I. Helping contributors get started >>>>>>> >>>>>>> It isn?t as easy to get started with OpenJFX as it should be. We want >>>>>>> >>>>>>> >>>>>> to >>>>>> >>>>>> >>>>>>> make it easier for potential OpenJFX contributors to get started. >>>>>>> >>>>>>> >>>>>> Here >>> >>> >>>> are some ideas that I think might help: >>>>>>> >>>>>>> * Improve the build instructions / Wiki (I made a first start, but >>>>>>> >>>>>>> >>>>>> there >>>>>> >>>>>> >>>>>>> is much more to be done) >>>>>>> >>>>>>> * Make the build itself more resilient where possible, and provide >>>>>>> better error messages, specifically when dealing with native >>>>>>> >>>>>>> >>>>>> compilers >>> >>> >>>> and libraries >>>>>>> >>>>>>> * Add an option to skip building all native code and use prebuilt >>>>>>> binaries (like we do already for media and webkit); this is tracked >>>>>>> >>>>>>> >>>>>> by >>> >>> >>>> JDK-8092279, but it hasn?t been looked at recently >>>>>>> >>>>>>> * Make it easier to build / test your local OpenJFX build using an >>>>>>> OpenJDK build (currently the only way to do this is to build OpenJDK >>>>>>> locally, after using configure to point to your just-built javafx.* >>>>>>> modules). >>>>>>> >>>>>>> * Provide step-by-step instructions for how to make a contribution, >>>>>>> including testing requirements; a lot of the pieces are there, but >>>>>>> >>>>>>> >>>>>> are >>> >>> >>>> out of date or scattered in several places. As part of this, we could >>>>>>> have a section on how to contribute docs, samples or tests, since >>>>>>> >>>>>>> >>>>>> that >>> >>> >>>> is often a good place to start. >>>>>>> >>>>>>> * Provide a sandbox environment where contributors can discuss and >>>>>>> >>>>>>> >>>>>> test >>> >>> >>>> ideas. For example, an OpenJFX mirror on github, potentially >>>>>>> >>>>>>> >>>>>> connected >>> >>> >>>> to AdoptOpenJDK. >>>>>>> >>>>>>> >>>>>>> II. Code reviews and API reviews >>>>>>> >>>>>>> Code reviews are important to maintain high-quality contributions, >>>>>>> >>>>>>> >>>>>> but >>> >>> >>>> we recognize that not every type of change needs the same level of >>>>>>> review. Without lowering our standards of quality, we want to make it >>>>>>> easier to get low-impact changes (simple bug fixes) accepted. >>>>>>> >>>>>>> There are three categories of changes, each of which might merit a >>>>>>> different review standard: >>>>>>> >>>>>>> 1. Low-impact bug fixes. These are typically isolated bug fixes with >>>>>>> little or no impact beyond fixing the bug in question; included in >>>>>>> >>>>>>> >>>>>> this >>> >>> >>>> category are test fixes (including new tests) doc fixes, and fixes to >>>>>>> sample applications (including new samples). >>>>>>> >>>>>>> 2. Higher impact bug fixes or RFEs. These include changes to the >>>>>>> implementation that potentially have a performance or behavioral >>>>>>> >>>>>>> >>>>>> impact, >>>>>> >>>>>> >>>>>>> or are otherwise broad in scope. Some larger bug fixes will fall into >>>>>>> this category, as will fixes in high-risk areas (e.g., CSS). >>>>>>> >>>>>>> 3. New features / API additions. In addition to reviewing the >>>>>>> implementation, we will need a separate approval process for the new >>>>>>> >>>>>>> >>>>>> API >>>>>> >>>>>> >>>>>>> / feature (such as the CSR, which is what we use now, or a similar >>>>>>> process). >>>>>>> >>>>>>> We take compatibility seriously, so anything that adds new API needs >>>>>>> >>>>>>> >>>>>> to >>> >>> >>>> be done with an eye towards supporting it for at least 10 years. We >>>>>>> don't want to add new public API without that level of commitment. >>>>>>> >>>>>>> >>>>>> Every >>>>>> >>>>>> >>>>>>> new feature forecloses on alternate future features. Significant >>>>>>> >>>>>>> >>>>>> effort >>> >>> >>>> must be taken to think about "if we did this, what could it interact >>>>>>> with in the future?" Also, anything with a large potential impact on >>>>>>> performance or behavioral compatibility needs to be looked at >>>>>>> >>>>>>> >>>>>> carefully. >>>>>> >>>>>> >>>>>>> Put another way, we want to encourage thinking about new features or >>>>>>> >>>>>>> >>>>>> new >>>>>> >>>>>> >>>>>>> API in terms of a design / stewardship process; to think in terms of >>>>>>> questions like "what's the right thing for JavaFX in the next 10+ >>>>>>> >>>>>>> >>>>>> years" >>>>>> >>>>>> >>>>>>> rather than "here's some code that solves my problem, please take >>>>>>> >>>>>>> >>>>>> it". >>> >>> >>>> As a stake in the ground, I might suggest the following: >>>>>>> >>>>>>> * All changes need at least one reviewer other than the person making >>>>>>> the change who can evaluate the change for correctness and >>>>>>> >>>>>>> >>>>>> consistency. >>> >>> >>>> For simple bug fixes, a single reviewer may be sufficient. Of course, >>>>>>> one of our big challenges in all this is: "how do we grow more >>>>>>> reviewers?", by which I mean "how do we facilitate getting >>>>>>> >>>>>>> >>>>>> contributors >>> >>> >>>> with enough expertise in a given area to eventually be able to >>>>>>> effectively review contributions from others?" >>>>>>> >>>>>>> * We need clear criteria for the other two categories that balance >>>>>>> process efficiency with the desire to maintain compatibility and >>>>>>> stability. API changes need to be approved by a lead. My thought is >>>>>>> >>>>>>> >>>>>> to >>> >>> >>>> combine the last two into a single category for purposes of reviewing >>>>>>> the implementation. Anything that affects public API or behavioral >>>>>>> compatibility will require CSR or similar approval, over and above >>>>>>> >>>>>>> >>>>>> the >>> >>> >>>> implementation review, which seems sufficient. >>>>>>> >>>>>>> * I recommend that we formalize the concept of reviewers, using the >>>>>>> OpenJDK Reviewer role for the Project. We might also consider if we >>>>>>> >>>>>>> >>>>>> want >>>>>> >>>>>> >>>>>>> to make any changes to the criteria used by the JDK Project for >>>>>>> >>>>>>> >>>>>> becoming >>>>>> >>>>>> >>>>>>> an OpenJFX Project Author, Committer, and Reviewer. The OpenJDK >>>>>>> >>>>>>> >>>>>> bylaws >>> >>> >>>> allow projects a fair degree of latitude to define these criteria, so >>>>>>> >>>>>>> >>>>>> we >>>>>> >>>>>> >>>>>>> might consider making some modifications. For example, we might make >>>>>>> >>>>>>> >>>>>> it >>> >>> >>>> somewhat easier for a Contributor to become an Author, or for a >>>>>>> Committer to become a Reviewer. I have some thoughts on this, but >>>>>>> >>>>>>> >>>>>> want >>> >>> >>>> to hear from others first. >>>>>>> >>>>>>> >>>>>>> I look forward to feedback on this proposal, and hope it will spark a >>>>>>> productive discussion. >>>>>>> >>>>>>> -- Kevin Rushforth, OpenJFX Project Lead >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>
