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.en...@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 <nlis...@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.en...@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 <nlis...@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.rushfo...@oracle.com>
To: "openjfx-dev@openjdk.java.net" <openjfx-dev@openjdk.java.net>
Subject: More community participation in JavaFX
Message-ID: <5a73a220.7030...@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
