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