More community participation in JavaFX
John-Val Rose
johnvalrose at gmail.com
Wed Feb 7 18:09:00 UTC 2018
Yes, I agree - sorry.
I got a bit confused as to which thread I was “in” (while reading messages from each of them simultaneously) and there’s definitely a degree of overlap between the two of them topic-wise.
Anyway, I vented - just not in the right place. I still hope for some feedback on said venting...
> On 8 Feb 2018, at 03:42, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>
> This has now veered off topic for this thread. It would be a fine topic for the "future content of OpenJFX" thread.
>
> -- Kevin
>
>
> John-Val Rose wrote:
>> <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