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