[8u, 11u] Wiki Page updates

[Langer, Christoph]

Hi Aleksey,

> It is a good start, but I feel it does not help the outsiders, who would be as
> puzzled after reading that page.

yeah, I tend to agree...

> Concrete suggestions:
> 
>  *) Let's spell out:
>      "Current status:
>        jdk-updates/jdk11u-dev repository collects non-critical update fixes,
> targeted to 11.0.4.
>        jdk-updates/jdk11u repository is stabilizing for 11.0.3 release"
> 

Good idea. I'll add that section.

With that section it is important, though, that we keep it up to date. Maybe I shall also create a "release engineers recipe/to do list" for things to do during a release cycle, e.g. bump version numbers, set initial tags, branches etc. Probably worth another Wiki page. I'll look into that, too.

>  *) We need a verbose "How Do I" section, for example
> 
>  ------ 8< -----------------------------------------------------------------------
> How Do I...
> 
> ...Suggest the Change
> 
> Normally, requesters are expected to do the bulk of the backporting work. If
> do not have time and
> resources to do the work, you have to find someone who would. You can ask
> around the original
> authors of the change and/or current (co-)maintainers in the update release.
> 
> ...Request the Backport
> 
> Backports are the issues that exist in later JDK versions and need to be
> applied to lower ones as well.
> 
>  1. Pick the existing issue from the JBS
>       - Take careful note of the linked issues that need to be brought with
>         the fix, especially the follow-up fixes;
>       - If there are relevant issues that prevent clean backport, consider
> backporting
>         those first (within reason)
>  2. Check out the jdk-updates/jdk11u-dev, and try to apply the patch there
>       - Make sure to keep the changeset metadata: original authors, Reviewed-
> by: lines, etc
>  3. If patch does not apply cleanly, you have to start the RFR thread at jdk-
> updates-dev@
>       - Need to state what changes were needed and why
>       - Optionally, seek the review from the original authors
>  4. Test the patch
>       - "tier1" tests should be passing at all times
>       - Look at what area the patch affects, and run the tests from there
>       - New regression tests that come with the patch should pass
>       - Optionally, new regression tests may need to be verified to fail without
> the patch
>  5. Once everything is done, put jdk11u-fix-request tag and the "Fix Request"
> comment on the issue
>       - Fix Request should explain why the fix should be backported, what
> testing was done,
>         and the risk estimate
>  6. Wait for maintainer approval, which would manifest as jdk11u-fix-yes tag
> on the issue
>  7. Push the change
>       - You might need a sponsor in jdk-updates project, ask at jdk-updates-
> dev@ list
>  8. Wait around to resolve any problems that might arise from the push
> 
> 
> ...Request the Change (without Backport)
> 
> There are cases when the lower JDK release needs to have the patch that is
> not required for the
> higher JDK releases. The same rule set applies, as for backports, with
> mandatory RFR at
> jdk-updates-dev list.
> 
> 
> ...Keep the Changeset Metadata
> 
> The easiest way to keep metadata is to import the full changeset from
> Mercurial.
> <mq example goes here>
> 
> ...Test the Change
> 
> <jtreg example goes here>
> 
> ...Submit the RFR (Request For Review)
> 
> <RFR template goes here>
> 
>  ------ 8< -----------------------------------------------------------------------

That's also a very good idea. I will look into adding such a HowTo starting off with your proposal. Do you think it should be on the main page or shall I create a separate page and link to it? It's quite a bit content and might bloat the main page.

It's also maybe a bit orthogonal to Severin's guide: https://wiki.openjdk.java.net/display/JDKUpdates/JDK+Updates+Guidance. 

Best regards
Christoph