More community participation in JavaFX

[Johan Vos]

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 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> 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> 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>
> > 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> 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).
> >>> * 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).
> >>>
> >>> --- 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>
> >>> > To: "openjfx-dev at openjdk.java.net" <openjfx-dev at openjdk.java.net>
> >>> > Subject: More community participation in JavaFX
> >>> > Message-ID: <5A73A220.7030706 at oracle.com>
> >>> > Content-Type: text/plain; charset=windows-1252; format=flowed
> >>> >
> >>> > To: OpenJFX Developers
> >>> >
> >>> > We are looking to grow the community of contributors to the OpenJFX
> >>> > project, especially serious contributors who will stick around long
> >>> > enough to become reviewers, to help us keep the platform vibrant. To
> >>> > this end we are looking at ways to encourage more participation and
> >>> make
> >>> > it easier for interested folks to contribute.
> >>> >
> >>> > We are specifically looking to discuss ideas around the following
> >>> areas:
> >>> >
> >>> > * Easing barriers to contribution (e.g., making JavaFX easier to
> build,
> >>> > better documentation, making it easier to test changes)
> >>> >
> >>> > * Code review policies
> >>> >
> >>> > * API / feature review policies
> >>> >
> >>> > * Code review tools (we currently use webrev, but that isn't set in
> >>> stone)
> >>> >
> >>> >
> >>> > To keep this thread productive, the following are explicitly out of
> >>> scope:
> >>> >
> >>> > * Discussion of specific features or bugs that you would like to
> >>> > implement (or wish someone else would)
> >>> >
> >>> > * Discussion about platform support
> >>> >
> >>> > * Discussion about version control systems (e.g., hg versus git),
> >>> > hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus
> >>> > github), etc...at least for now. We are aware of the potential
> benefits
> >>> > of such changes, but we'd like to focus our efforts on
> higher-leverage
> >>> > things we can do in the short term.
> >>> >
> >>> > * Discussion about the requirement of a signed OCA to become a
> >>> contributor
> >>> >
> >>> > * Off-topic or tangential commentary about OpenJFX that isn't
> directly
> >>> > related to the topic at hand
> >>> >
> >>> >
> >>> > As a starting point for discussion, here are some areas I think need
> >>> > improvement; I'm sure there are others:
> >>> >
> >>> > I. Helping contributors get started
> >>> >
> >>> > It isn?t as easy to get started with OpenJFX as it should be. We want
> >>> to
> >>> > make it easier for potential OpenJFX contributors to get started.
> Here
> >>> > are some ideas that I think might help:
> >>> >
> >>> > * Improve the build instructions / Wiki (I made a first start, but
> >>> there
> >>> > is much more to be done)
> >>> >
> >>> > * Make the build itself more resilient where possible, and provide
> >>> > better error messages, specifically when dealing with native
> compilers
> >>> > and libraries
> >>> >
> >>> > * Add an option to skip building all native code and use prebuilt
> >>> > binaries (like we do already for media and webkit); this is tracked
> by
> >>> > JDK-8092279, but it hasn?t been looked at recently
> >>> >
> >>> > * Make it easier to build / test your local OpenJFX build using an
> >>> > OpenJDK build (currently the only way to do this is to build OpenJDK
> >>> > locally, after using configure to point to your just-built javafx.*
> >>> > modules).
> >>> >
> >>> > * Provide step-by-step instructions for how to make a contribution,
> >>> > including testing requirements; a lot of the pieces are there, but
> are
> >>> > out of date or scattered in several places. As part of this, we could
> >>> > have a section on how to contribute docs, samples or tests, since
> that
> >>> > is often a good place to start.
> >>> >
> >>> > * Provide a sandbox environment where contributors can discuss and
> test
> >>> > ideas. For example, an OpenJFX mirror on github, potentially
> connected
> >>> > to AdoptOpenJDK.
> >>> >
> >>> >
> >>> > II. Code reviews and API reviews
> >>> >
> >>> > Code reviews are important to maintain high-quality contributions,
> but
> >>> > we recognize that not every type of change needs the same level of
> >>> > review. Without lowering our standards of quality, we want to make it
> >>> > easier to get low-impact changes (simple bug fixes) accepted.
> >>> >
> >>> > There are three categories of changes, each of which might merit a
> >>> > different review standard:
> >>> >
> >>> > 1. Low-impact bug fixes. These are typically isolated bug fixes with
> >>> > little or no impact beyond fixing the bug in question; included in
> this
> >>> > category are test fixes (including new tests) doc fixes, and fixes to
> >>> > sample applications (including new samples).
> >>> >
> >>> > 2. Higher impact bug fixes or RFEs. These include changes to the
> >>> > implementation that potentially have a performance or behavioral
> >>> impact,
> >>> > or are otherwise broad in scope. Some larger bug fixes will fall into
> >>> > this category, as will fixes in high-risk areas (e.g., CSS).
> >>> >
> >>> > 3. New features / API additions. In addition to reviewing the
> >>> > implementation, we will need a separate approval process for the new
> >>> API
> >>> > / feature (such as the CSR, which is what we use now, or a similar
> >>> > process).
> >>> >
> >>> > We take compatibility seriously, so anything that adds new API needs
> to
> >>> > be done with an eye towards supporting it for at least 10 years. We
> >>> > don't want to add new public API without that level of commitment.
> >>> Every
> >>> > new feature forecloses on alternate future features. Significant
> effort
> >>> > must be taken to think about "if we did this, what could it interact
> >>> > with in the future?" Also, anything with a large potential impact on
> >>> > performance or behavioral compatibility needs to be looked at
> >>> carefully.
> >>> >
> >>> > Put another way, we want to encourage thinking about new features or
> >>> new
> >>> > API in terms of a design / stewardship process; to think in terms of
> >>> > questions like "what's the right thing for JavaFX in the next 10+
> >>> years"
> >>> > rather than "here's some code that solves my problem, please take
> it".
> >>> >
> >>> >
> >>> > As a stake in the ground, I might suggest the following:
> >>> >
> >>> > * All changes need at least one reviewer other than the person making
> >>> > the change who can evaluate the change for correctness and
> consistency.
> >>> > For simple bug fixes, a single reviewer may be sufficient. Of course,
> >>> > one of our big challenges in all this is: "how do we grow more
> >>> > reviewers?", by which I mean "how do we facilitate getting
> contributors
> >>> > with enough expertise in a given area to eventually be able to
> >>> > effectively review contributions from others?"
> >>> >
> >>> > * We need clear criteria for the other two categories that balance
> >>> > process efficiency with the desire to maintain compatibility and
> >>> > stability. API changes need to be approved by a lead. My thought is
> to
> >>> > combine the last two into a single category for purposes of reviewing
> >>> > the implementation. Anything that affects public API or behavioral
> >>> > compatibility will require CSR or similar approval, over and above
> the
> >>> > implementation review, which seems sufficient.
> >>> >
> >>> > * I recommend that we formalize the concept of reviewers, using the
> >>> > OpenJDK Reviewer role for the Project. We might also consider if we
> >>> want
> >>> > to make any changes to the criteria used by the JDK Project for
> >>> becoming
> >>> > an OpenJFX Project Author, Committer, and Reviewer. The OpenJDK
> bylaws
> >>> > allow projects a fair degree of latitude to define these criteria, so
> >>> we
> >>> > might consider making some modifications. For example, we might make
> it
> >>> > somewhat easier for a Contributor to become an Author, or for a
> >>> > Committer to become a Reviewer. I have some thoughts on this, but
> want
> >>> > to hear from others first.
> >>> >
> >>> >
> >>> > I look forward to feedback on this proposal, and hope it will spark a
> >>> > productive discussion.
> >>> >
> >>> > -- Kevin Rushforth, OpenJFX Project Lead
> >>> >
> >>>
> >>
> >>
> >
>