[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: PLEASE READ: Changes needed to make and keep JavaFX repos "jcheck clean"
From:       Kevin Rushforth <kevin.rushforth () oracle ! com>
Date:       2016-01-20 2:02:17
Message-ID: 569EEAA9.50402 () oracle ! com
[Download RAW message or body]

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
>
[prev in list] [next in list] [prev in thread] [next in thread]