PLEASE READ: Changes needed to make and keep JavaFX repos "jcheck clean"

[Kevin Rushforth]

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