More community participation in JavaFX

[Nir Lisker]

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>
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
>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>