More community participation in JavaFX
John-Val Rose
johnvalrose at gmail.com
Wed Feb 7 07:37:45 UTC 2018
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