All,
This is a bit long, but please read it if you are a JavaFX developer who
either pushes or authors changesets (or hopes to do so soon).
EXECUTIVE SUMMARY
We plan to enable jcheck in the (I hope) not too distant future. We will
need help from all developers to follow best practices to make the
transition as painless as possible, specifically you will need to take
extra care in creating changesets prior to pushing them to our forest.
DETAILS
I think all OpenJFX committers are (painfully) aware that JavaFX lacks
the automatic updating JBS issues provided by hgupdater, including:
* Adding the changeset URL as a comment when a changeset is pushed
* Resolving the JIRA issue as fixed
* Creating a backport record if necessary
* Updating the "resolved in build" field
In order to enable hgupdater we need to enable jcheck for the OpenJFX
repositories in each forest. In addition to the primary benefit of
allowing us to use hgupdater, the other benefit jcheck gives us is
enforcing good practices, like making sure we don't have DOS line
endings and other whitespace issues that serve only as sources of merge
conflict and inconsistency.
I have filed an umbrella task [1] in JBS to track the necessary tasks
needed to enable jcheck, and I will be filing individual RFEs (or bugs)
to track the specific tasks.
This will require some additional restrictions on changesets. The three
main things that developers need to be aware of are:
1. Changeset comments must adhere to the proper format defined in the
openjdk Wiki [2]. This means that *all* non-merge changesets must start
with a 7 digit bug ID, followed by a colon ":" followed by the bug
title. It also means that every changeset must have a unique bug ID. No
more "quick and dirty" fixes like "Oops, fix the build" or "[TOYS] added
a quick test program" or "Follow-on fix for 8888888". We should get in
the habit now, so I will be monitoring and sending private e-mail to you
if I see a non-compliant changeset. This rule does not apply to
sandboxes like jake since these changesets will never be pushed directly
to mainline. The only variance is that the "Reviewed-by" field is still
optional for FX, but if present it must following the correct format.
2. White space rules will be enforced. Specifically, jcheck will
disallow TAB characters, DOS-style line endings, or trailing white space
in any source code file.
3. No executable files are allowed. In UNIX parlance this means that
every managed file in our repo must have "644" as the permission. I
don't think this will cause us problem in practice.
NEXT STEPS
For the existing files in the repo, we will have a "flag day" where I
(with help from Dave Hill who has volunteered to assist) will push two
changesets to each repository: one changeset to fix the file permissions
(#3 above) and one to fix the whitespace (#2 above). This will likely
happen in the next week or so, after the 8u72 changes are synced back
into 8u-dev (and corresponding changes synced back into 9-dev), but
ideally before we fork the stabilization repos for 8u76.
I will follow-on with more information, specifically the details of the
"flag day" and what you can do to help ensure that it stays clean, but
wanted to give a heads-up that this was coming.
Let me know if you have any questions.
-- Kevin
[1] https://bugs.openjdk.java.net/browse/JDK-8145561
[2] http://openjdk.java.net/guide/producingChangeset.html
