[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: JavaFX roadmap
From:       Kevin Rushforth <kevin.rushforth () oracle ! com>
Date:       2018-05-24 14:36:56
Message-ID: f6b16fa6-e31c-51c1-716e-ec9230b88add () oracle ! com
[Download RAW message or body]

[changing the subject so we can keep the threads separate]

I think Johan hits the nail on the head here. Realistically, "large 
feature X" is only going to happen if there are enough resources to make 
it happen. Of course smaller features / enhancements can be done by 
part-time contributors, but even then we need to be careful to avoid 
"drive by" features.

As for an overarching roadmap, that seems like something that we (Gluon, 
Oracle, the OpenJFX community) can work on over the next little while. 
As Johan indicated, it needs to be tempered with reality.

-- Kevin


On 5/24/2018 6:03 AM, Johan Vos wrote:
> Hi Paul,
>
> That is a great question, and it has surfaced a number of times here.
> In my opinion, the direction of the project is mainly determined by the
> contributors. In a good eco-system, this lead to good results.
> In general, I think that if there is a large interest from many companies
> and individual to have feature X in JavaFX, it is more likely to happen
> because I assume that those companies have contributors working on OpenJFX,
> or they might pay other companies or individuals to work on it. In the end,
> roadmaps result in work to be done, so someone has to do the job. If there
> is enough interest in something, it will be easier to find someone or some
> people who will do it.
>
> Having said that, I'm all in for a more general, high-level roadmap, as
> long as it is always checked with reality, which (whether we like it or
> not) comes down to who wants to contribute resources.
>
> While this probably sounds very commercial coming from an open-source
> person, I realise that in order to keep open-source projects alive, there
> should be a clear connection with what customers in the end would like to
> have.
>
> - Johan
>
>
>
>
>
> On Thu, May 24, 2018 at 2:41 PM Paul Ray Russell <paulrussell70@gmail.com>
> wrote:
>
>>   "and the desired direction of the Project" - perhaps, Kevin, it would be
>> worth you taking a few words describing what this "direction" is. We all
>> know with JFX is currently, but what is the future direction? What are
>> contributors working towards in the long run? I'm sure we've all got our
>> own personal areas of interest, and it's surely motivational to hold onto a
>> less than broad idea of this.
>>
>> Best,
>> Paul
>>
>> On 24 May 2018 at 13:00, <openjfx-dev-request@openjdk.java.net> wrote:
>>
>>> Send openjfx-dev mailing list submissions to
>>>          openjfx-dev@openjdk.java.net
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>          http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
>>> or, via email, send a message with subject or body 'help' to
>>>          openjfx-dev-request@openjdk.java.net
>>>
>>> You can reach the person managing the list at
>>>          openjfx-dev-owner@openjdk.java.net
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of openjfx-dev digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>     1. OpenJFX code review policies, etc. (Kevin Rushforth)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Wed, 23 May 2018 15:16:49 -0700
>>> From: Kevin Rushforth <kevin.rushforth@oracle.com>
>>> To: "openjfx-dev@openjdk.java.net" <openjfx-dev@openjdk.java.net>
>>> Subject: OpenJFX code review policies, etc.
>>> Message-ID: <a753ebbb-b793-9400-2515-37330ee0c0db@oracle.com>
>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>>
>>> To: OpenJFX Developers
>>>
>>> As I mentioned in a message last week [1] I would like to restart the
>>> discussion we started a few months ago [2] around making it easier to
>>> contribute code to OpenJFX. To this end, I like to make some concrete
>>> proposals around code review / API review policies.
>>>
>>> Before getting to the details, I would like to acknowledge Gluon's
>>> contributions to the OpenJFX project, specifically those of Johan Vos. I
>>> am pleased to announce an expanded role for Johan Vos in the OpenJFX
>>> project. I would like to announce that starting now, Johan is
>>> effectively a co-lead for the purposes of setting direction, and
>>> approving new features for the Project.
>>>
>>> The short version of the proposal is:
>>>
>>> 1. Formalize the concept of Reviewers with an initial list of Reviewers
>>> and a defined criteria for adding additional Reviewers.
>>>
>>> 2. Revised code review policies for different types of changes: simple,
>>> low-impact fixes (1 Reviewer); higher-impact fixes (2 Reviewers + allow
>>> time for others to chime in); Features / API changes (CSR approval,
>>> including approval by a "lead", plus 3 Reviewers for the code)
>>>
>>> 3. Streamlining reviews of changes developed in the GitHub sandbox:
>>> provided that the review policy is followed to before a PR is merged
>>> into the develop branch in GitHub, a fast-track review can happen
>>> pointing to the changeset that was merged and the PR, which has review
>>> comments.
>>>
>>> Details follow.
>>>
>>> Quoting from my earlier message:
>>>
>>>> "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."
>>> To that end, I propose the following policies. Many of these will
>>> involve judgment calls, especially when it comes to deciding whether a
>>> fix is low impact vs. high-impact. I think that's OK. It doesn't have to
>>> be perfect.
>>>
>>> Recommendations
>>>
>>> 1. I recommend that we formalize the concept of Reviewers, using the
>>> OpenJDK Reviewer role for the OpenJFX Project.
>>>
>>> A. I will provide an initial list of reviewers to the registrar based on
>>> past contributions, and also recognizing Committers who have become
>>> experts in their area. This is the only time we will have such latitude
>>> as the OpenJDK Bylaws specify the policy we need to follow for
>>> nominating and voting upon additional Reviewers.
>>>
>>> B. We need to set formal guidelines for becoming a Reviewer. The JDK
>>> uses a threshold of 32 significant contributions. While we don't want to
>>> relax it too much, one thing I have been discussing informally with a
>>> few people is that a Committer with, say, 24 commits, who regularly
>>> participates in reviews, offering good feedback, might be just a good a
>>> reviewer (maybe even better) than someone with 32 commits who rarely, if
>>> ever, provides feedback on proposed bug fixes. I'm open for suggestions
>>> here.
>>>
>>> One thing I'd like to add is that we expect Reviewers to feel
>>> responsible not just for their piece, but for the quality of the JavaFX
>>> library as a whole. I might work with some folks at Gluon and here at
>>> Oracle to draft a set of expectations for reviewers.
>>>
>>>
>>> 2. Code review policies
>>>
>>> All code reviews must be posted on the openjfx-dev mailing list -- even
>>> simple fixes. I propose that we have the following code review policies
>>> for different types of changes. I also note that if there is
>>> disagreement as to whether a fix is low-impact or high-impact, then it
>>> is considered high-impact. In other words we will always err on the side
>>> of quality by "rounding up" to the next higher category. The contributor
>>> can say whether they think something is low-impact or high-impact, but
>>> It is up to a Reviewer to initially decide this.
>>>
>>> A. 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).
>>>
>>> One reviewer is sufficient to accept such changes. As a courtesy, and to
>>> avoid changes which later might need to be backed out, if you think
>>> there might be some concern or objection to the change, please give
>>> sufficient time for folks who might be in other time zones the chance to
>>> take a look. This should be left up to the judgment of the reviewer who
>>> approves it as well as the contributor.
>>>
>>> B. 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).
>>>
>>> Two reviewers must approve to accept such changes. Additionally, the
>>> review should allow sufficient time for folks who might be in other time
>>> zones the chance to review if they have concerns.
>>>
>>> C. New features / API additions. This includes behavioral changes,
>>> additions to the fxml or css spec, etc.
>>>
>>> Feature requests come with a responsibility beyond just saying "here is
>>> the code for this cool new feature, please take it". There are many
>>> factors to consider for even small features. Larger features will need a
>>> significant contribution in terms of API design, coding, testing,
>>> maintainability, etc.
>>>
>>> To ensure that new features are consistent with the rest of the API and
>>> the desired direction of the Project, I propose that a New Feature, API
>>> addition, or behavioral change must be reviewed / approved by a "lead".
>>> Currently this is either myself or Johan Vos as indicated above.
>>>
>>> I also propose that we continue to use the CSR process [3] to track such
>>> changes. The CSR chair has indicated that he is willing to track JavaFX
>>> compatibility changes even though FX is no longer a part of the JDK.
>>>
>>> For the review of the implementation, I propose that we use the same
>>> "two reviewer" standard for the code changes as category B.
>>>
>>>
>>> 3. Streamlining the review process for changes developed on GitHub
>>>
>>> A fix that was developed as pull-requests (PRs) on GitHub is eligible
>>> for a fast-track review, if:
>>>
>>> A. The PR was squashed / merged into the develop branch as a single
>>> changeset
>>> B. No follow-on changesets were merged into develop as part of that same
>>> fix
>>> C. The changeset is "whitespace clean" -- meaning that you have run
>>> 'tools/scripts/checkWhiteSpace' on the final changeset (we might want to
>>> add this to the CI build).
>>> and
>>> D. All code review policies outlined above in #2 were followed prior to
>>> the PR being approved and merged into the develop branch on GitHub. This
>>> includes sending email to openjfx-dev when you first make a PR that you
>>> intend to have merged into the develop branch to give other reviewers
>>> who may not be watching all PRs a chance to comment before it is merged.
>>>
>>> A "fast-track" review is a quick sanity check before the change is
>>> committed and pushed to the jfx-dev repo on hg.openjdk.java.net. This
>>> fast track review just needs to point to the GitHub changeset that was
>>> merged and to the PR, which will have any review comments. If there are
>>> no compelling reasons why the PR can't be pushed to jfx-dev, then it can
>>> be pushed.
>>>
>>>
>>> Please let me know your thoughts on the above proposals.
>>>
>>> Thank you all for being a part of this community.
>>>
>>> -- Kevin Rushforth, OpenJFX Project Lead
>>>
>>> [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-
>>> May/021867.html
>>>
>>> [2]
>>> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-
>>> February/021335.html
>>>
>>> [3] https://wiki.openjdk.java.net/display/csr/Main
>>>
>>>
>>>
>>> End of openjfx-dev Digest, Vol 78, Issue 39
>>> *******************************************
>>>

[prev in list] [next in list] [prev in thread] [next in thread]