More community participation in JavaFX
Tom Eugelink
tbee at tbee.org
Wed Feb 7 07:05:44 UTC 2018
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