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