Yeah - I looked at the windows build process recently - which was enough to dissuade me from starting. I do know JavaFX fairly well, and have a potted history working in software companies. I'd like to get on-board once I finish my current game. I'd be interested in game related areas; but realise these may not be areas of development that JavaFX was ever intended, or *will* ever be directed to cover. That would be another whole conversation to have.
If it's the case that JavaFX is to remain a GUI toolkit, with v. limited graphics abilities: something useful for front-ending business apps, but not much more, then it needs to be made clearer that this is the aim. The games community has grown despondent about JavaFX as a framework, which is a shame. I see evidence of this scattered all over the web. Too many abandoned projects from 2013 era. It's all bit depressing. It's such a great framework. On 2 February 2018 at 00:07, <openjfx-dev-requ...@openjdk.java.net> wrote: > Send openjfx-dev mailing list submissions to > openjfx-dev@openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev > or, via email, send a message with subject or body 'help' to > openjfx-dev-requ...@openjdk.java.net > > You can reach the person managing the list at > openjfx-dev-ow...@openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openjfx-dev digest..." > > > Today's Topics: > > 1. More community participation in JavaFX (Kevin Rushforth) > 2. Re: More community participation in JavaFX (Michael Ennen) > 3. Re: More community participation in JavaFX (Richard Steiger) > > > ---------------------------------------------------------------------- > > 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 > > > > ------------------------------ > > Message: 2 > Date: Thu, 1 Feb 2018 16:58:52 -0700 > From: Michael Ennen <mike.en...@gmail.com> > To: Kevin Rushforth <kevin.rushfo...@oracle.com> > Cc: "openjfx-dev@openjdk.java.net" <openjfx-dev@openjdk.java.net> > Subject: Re: More community participation in JavaFX > Message-ID: > <CAOTPd66cX4Fe-UOE-VM-BuQqDBRWDG11S3qP+54X- > gzmnot...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > I think that having a public sandbox mirror on GitHub, as you mentioned, is > a great idea. > > The idea is that PRs could be opened and the test suites could be run using > CI for the > platforms supported by JavaFX. The PR itself would never be directly merged > into the > OpenJFX hg repository. Instead the PR would be a launching point that > provides a means > for review and feedback. Once all feedback is taken into account, the PR > can be marked > as "Ready" which means it is ready to move up to the more formal review > processes > already in place. Automating the creation of a webrev for the PR, as well > as converting > the git PR to a mercurial one would make the process streamlined and > efficient. > > I only mention GitHub because I think it would allow for the smallest > barrier of entry and > cast the widest net of potential contributors. Setting up this mirroring > infrastructure wouldn't > be a simple task but it is very doable IMO. I messed around with creating > Travis and Appveyor > CI builds for openjfx and besides running up against a 45 minute time limit > I didn't encounter > any show-stoppers. > > I believe we need such a sandbox to act as a "staging ground" or an adapter > between the > high barrier to entry and first-time or new contributions. The only way it > would work, > in my opinion, is that there is a vibrant community of reviewers who, in > their free time, > help get the PRs in shape to move to the next level (which is the more > formal processes > that already exist, as you mentioned). > > Thanks for starting this important discussion, Kevin. > > -- Michael Ennen > > On Thu, Feb 1, 2018 at 4:26 PM, Kevin Rushforth < > kevin.rushfo...@oracle.com> > wrote: > > > 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 > > > > > > > ------------------------------ > > Message: 3 > Date: Thu, 1 Feb 2018 16:03:06 -0800 > From: Richard Steiger <rstei...@ensemblesoft.net> > To: openjfx-dev@openjdk.java.net > Subject: Re: More community participation in JavaFX > Message-ID: <feaca3e4-1cda-dd1d-4d13-18d4f7bca...@ensemblesoft.net> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Hi Kevin, > > As a long-time observer of the OpenJFX project, let me put all my chips > at this point on making builds more stable, bullet-proof, and automated, > and give equal weight making them so on Win10 and OS/X, specifically, > the same weight as is given to making building and developing on Linux > work well. > > Over the last 3 or so years, on at least 3 separate occasions, I've > gotten a head of inspirational steam to try-out some new features (the > latest being using byte-code engineering to radically streamline > binding, rendering most of the current API obsolete, and hugely > improving performance).? I then attempt to build the whole project from > sources (not always required, but essential when it is) on Win10, my > development platform of choice, and invariably get wound around the axel > of no-longer published VS tooling, missing binaries, and other > show-stopper glitches. > > Like many potential contributors, I've got a day job, plus am trying to > launch a garage startup, so my time is a very scarce resource.? I simply > don't have the extra cycles to troubleshoot highly convoluted builds (of > which OpenJFX is one of the worst I've seen), so my head of steam > bleeds-off for another year or so.? Nor am I willing to switch to a > Linux development environment, remap my motor memory, take-on care and > feeding of another platform (Windows and OS/X suck enough time, and are > essential for my business).? Every time I've hit this wall, I've puzzled > over how the team has tolerated the situation, and moved on. > > So, to be redundant, all the other issues you've so cogently enumerated > pale in the face of development portability, starting with build > stability and cleanliness on widely-used platforms. > > Thanks for considering the above input. > > -rjs > > > On 2/1/18 3:26 PM, Kevin Rushforth wrote: > > 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 > > > > > > End of openjfx-dev Digest, Vol 75, Issue 4 > ****************************************** >
