More community participation in JavaFX
Hervé Girod
herve.girod at gmail.com
Wed Feb 7 10:47:00 UTC 2018
I have coded such a framework in one of my open source projects. I can extract this code and setup a github project for it if people are interested.
Hervé
Sent from my iPhone
> On Feb 7, 2018, at 10:52, John-Val Rose <johnvalrose at gmail.com> 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