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