More community participation in JavaFX
John-Val Rose
johnvalrose at gmail.com
Wed Feb 7 09:52:28 UTC 2018
<rant>
Well, not only do I think that a docking framework is *that* complex, I see it as an essential part of any serious graphics toolkit.
In general, I don’t understand all the limitations that people keep imposing on JavaFX as if we have to “settle” for what is basically a 2nd class citizen compared with toolkits in other languages.
Why can’t we just make JavaFX so compelling that developers from other languages are enticed by the feature set itself? There is no reason (other than a lack of effort) why JavaFX cannot be on par with Qt or Xamarin in terms of features, performance, tooling and adoption.
Am I the only one that believes the world’s most popular and amazing programming language, platform and the JVM deserves a first class graphics toolkit?
I understand the constraints imposed on Oracle staff but isn’t there anyone else out there in the community who shares my vision for JavaFX?
It seems the general attitude is that JavaFX just needs to be a “better Swing”.
Forget about this nonsense of “thinking outside the box”.
There is NO BOX!
JavaFX can and should be the best that we as a community can make it.
And then we just keep making it better...
If we don’t adopt such a vision and attitude then what is the point of doing anything at all? Just leave JavaFX to rot into oblivion and relegate Java to a server-side language only.
</rant>
> On 7 Feb 2018, at 19:25, Tom Eugelink <tbee at tbee.org> wrote:
>
> Well, I believe he was hinting at that a docking framework is considered
> more complex, there was no negative sentiment in that. Although I do not
> think a docking framework is that complex, but maybe I'm wrong.
>
> And yes, ALMOST everyone is at ControlFX ;-)
>
>
>
>> Jonathan - why do you *cough* at ideas like more complex controls and
>> docking frameworks?
>>
>> I think that a docking framework especially would be a great addition to
>> JavaFX.
>>
>> Am I missing something?
>>
>>> On 7 Feb 2018, at 18:16, Jonathan Giles <jonathan at jonathangiles.net>
>>> wrote:
>>>
>>> Obviously everyone is at ControlsFX instead ;-)
>>>
>>> Part of the drop I would suggest is simply that many of the itches
>>> people
>>> want to scratch are now scratched. Alternatively, the remaining itches
>>> are
>>> either in more complex controls (*cough* docking frameworks *cough*) or
>>> in
>>> areas beneath the controls APIs - performance, webview, etc - which are
>>> more challenging and require greater levels of dedication.
>>>
>>> However, more generally, your point is well made - contribution to
>>> JavaFX
>>> does not need to be synonymous with contribution to OpenJFX. People who
>>> find the challenges of the current OpenJFX requirements too great should
>>> be
>>> encouraged to involve themselves in projects such as JFXtras, etc.
>>>
>>> -- Jonathan
>>>
>>>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink <tbee at tbee.org> wrote:
>>>>
>>>> Many years ago I had a discussion with Jonathan Giles about if the
>>>> things
>>>> that were being made in JFXtras would eventually become part of the
>>>> JavaFX
>>>> core. In the end I decided that, for me personally, I could do the
>>>> things I
>>>> wanted to perfectly in a separate project. The rigid structure that
>>>> Java(FX) has to adhere to, would be a big downside.
>>>>
>>>> What I want to say with that is that all the external projects are also
>>>> contributions to JavaFX. It does not matter whether for example a
>>>> control
>>>> is part of the core distribution or of a side project; it is just
>>>> another
>>>> module users can add to the mix.
>>>>
>>>> So reflecting back I still stand by that choice. But having a few more
>>>> people in the project (just like in JavaFX ;-) ) would be nice, but
>>>> OTOH it
>>>> forces me to deal with (and learn about) annoying stuff like Gradle
>>>> build
>>>> scripts and Java 9 migration. But because of that progress is not as
>>>> fast
>>>> as I would like it to be. Could it be that there is a decline in people
>>>> willing to work for open source projects? Or is it just that this tech,
>>>> JavaFX, is no longer appealing?
>>>>
>>>> Tom
>>>>
>>>>
>>>>
>>> Obviously everyone is at ControlsFX instead ;-)
>>>
>>> Part of the drop I would suggest is simply that many of the itches
>>> people
>>> want to scratch are now scratched. Alternatively, the remaining itches
>>> are
>>> either in more complex controls (*cough* docking frameworks *cough*) or
>>> in
>>> areas beneath the controls APIs - performance, webview, etc - which are
>>> more challenging and require greater levels of dedication.
>>>
>>> However, more generally, your point is well made - contribution to
>>> JavaFX
>>> does not need to be synonymous with contribution to OpenJFX. People who
>>> find the challenges of the current OpenJFX requirements too great should
>>> be
>>> encouraged to involve themselves in projects such as JFXtras, etc.
>>>
>>> -- Jonathan
>>>
>>>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink <tbee at tbee.org> wrote:
>>>>
>>>> Many years ago I had a discussion with Jonathan Giles about if the
>>>> things
>>>> that were being made in JFXtras would eventually become part of the
>>>> JavaFX
>>>> core. In the end I decided that, for me personally, I could do the
>>>> things I
>>>> wanted to perfectly in a separate project. The rigid structure that
>>>> Java(FX) has to adhere to, would be a big downside.
>>>>
>>>> What I want to say with that is that all the external projects are also
>>>> contributions to JavaFX. It does not matter whether for example a
>>>> control
>>>> is part of the core distribution or of a side project; it is just
>>>> another
>>>> module users can add to the mix.
>>>>
>>>> So reflecting back I still stand by that choice. But having a few more
>>>> people in the project (just like in JavaFX ;-) ) would be nice, but
>>>> OTOH it
>>>> forces me to deal with (and learn about) annoying stuff like Gradle
>>>> build
>>>> scripts and Java 9 migration. But because of that progress is not as
>>>> fast
>>>> as I would like it to be. Could it be that there is a decline in people
>>>> willing to work for open source projects? Or is it just that this tech,
>>>> JavaFX, is no longer appealing?
>>>>
>>>> Tom
>>>>
>>>>
>>>>
>>>>> On 7-2-2018 03:16, Kevin Rushforth wrote:
>>>>>
>>>>> I would recommend against having a separate issue tracker or mailing
>>>>> list
>>>>> associated with the sandbox. That will create more confusion than any
>>>>> benefit you might have.
>>>>>
>>>>> -- Kevin
>>>>>
>>>>>
>>>>> Nir Lisker wrote:
>>>>>
>>>>>> 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.rushforth at oracle.com <mailto:kevin.rushforth at 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
>>>>>> <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.ennen at gmail.com <mailto:mike.ennen at 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
>>>>>> <nlisker at gmail.com <mailto:nlisker at 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.ennen at gmail.com <mailto:mike.ennen at 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
>>>>>> <nlisker at gmail.com <mailto:nlisker at 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
>>>>>> <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
>>>>>> <http://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.rushforth at oracle.com
>>>>>> <mailto:kevin.rushforth at oracle.com>>
>>>>>> To: "openjfx-dev at openjdk.java.net
>>>>>> <mailto:openjfx-dev at openjdk.java.net>"
>>>>>> <openjfx-dev at openjdk.java.net
>>>>>> <mailto:openjfx-dev at openjdk.java.net>>
>>>>>> Subject: More community participation in
>>>>>> JavaFX
>>>>>> Message-ID: <5A73A220.7030706 at oracle.com
>>>>>> <mailto: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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>
More information about the openjfx-dev
mailing list