More community participation in JavaFX

[Paul Ray Russell]

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-request at openjdk.java.net> wrote:

> Send openjfx-dev mailing list submissions to
>         openjfx-dev at 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-request at openjdk.java.net
>
> You can reach the person managing the list at
>         openjfx-dev-owner at 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.rushforth at oracle.com>
> To: "openjfx-dev at openjdk.java.net" <openjfx-dev at openjdk.java.net>
> Subject: More community participation in JavaFX
> Message-ID: <5A73A220.7030706 at 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.ennen at gmail.com>
> To: Kevin Rushforth <kevin.rushforth at oracle.com>
> Cc: "openjfx-dev at openjdk.java.net" <openjfx-dev at openjdk.java.net>
> Subject: Re: More community participation in JavaFX
> Message-ID:
>         <CAOTPd66cX4Fe-UOE-VM-BuQqDBRWDG11S3qP+54X-
> GZmNoTVxg at 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.rushforth at 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 <rsteiger at ensemblesoft.net>
> To: openjfx-dev at openjdk.java.net
> Subject: Re: More community participation in JavaFX
> Message-ID: <feaca3e4-1cda-dd1d-4d13-18d4f7bca656 at 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
> ******************************************
>