More community participation in JavaFX
Kevin Rushforth
kevin.rushforth at oracle.com
Wed Feb 7 02:16:40 UTC 2018
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