We are targeting this Friday, Jan 22 as "white-space cleanup day" for
9-dev and 8u-dev. The reason for this accelerated timeline is that we
want to do it before RDP2 (RampDown Phase 2) of 8u76 to minimize the
merge conflicts that could otherwise happen.
Two things to note:
1) Dave will check in a script (and a gradle task to run the script) to
help check and fix white space problems so that we stay clean
2) We will send out detailed instructions on how to run the script(s) to
avoid problems and/or how to configure jcheck to manually do the
checking (you won't be able to run it via an hg hook yet).
-- Kevin
Kevin Rushforth wrote:
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
