JDK 11.0.3 Update process

[Aleksei Voitylov]

On 19/02/2019 01:49, Andrew Hughes wrote:
> n Mon, 18 Feb 2019 at 09:42, Andrew Haley <aph at redhat.com> wrote:
>> On 2/15/19 6:06 PM, Andrew Hughes wrote:
>>
>>> As I said before [0], I think the jdkxxu repository should be
>>> restricted, maintaining a clear distinction between a jdkxxu-dev
>>> branch for developers to commit to, and the jdkxxu for
>>> consumption. The latter is the one that would be frozen and used as
>>> the base for releases around CPU time.  That avoids a situation
>>> where people push stuff to jdkxxu in the interim and then are
>>> surprised when it's not in the release.
>>>
>>> If there's an issue with a lack of a maintainer, then that's a sign
>>> we need to appoint more, not abandon the whole idea.
>> I have thought some more about this, and I now believe there is a
>> deeper issue.
>>
>> The problem is that we've been conflating two roles in the
>> "maintainer". One is someone whose role is essentially judgemental:
>> they decide whether a patch is suitable for a particular release. The
>> other role is integrative: they merge a patch into a release branch
>> and make sure the result works by testing it. These two roles are not
>> the same thing, and require different skills.
>>
>> We are likely to encounter scaling problems as we work on the updates
>> projects and we will do ourselves no favours by creating bottlenecks
>> to efficient parallel working. A mature updates project would allow
>> many people, with different skills, to work together on a release
>> branch. Not all of these people would have the authority (or even the
>> desire) to approve patches.
>>
>> --
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> Indeed. In the Oracle sense, it is very much the former role of
> adjudicating on which changes make it to the release and which don't.
>
> The other role has been largely nameless, because that process is
> basically opaque under Oracle ownership; once they branch the tree
> (privately) for "RDP2", the only evidence we have of activity is entries
> in the bug database.
>
> So this is the area we really need to define more in-depth. At the end of
> day, primary responsibility will have to go to someone who can do TCK
> testing as any release should pass that. On what platforms that is the
> case is yet another issue, so the work may need to be distributed against
> multiple interested parties.
>
> OpenJDK 6 & 7 have been much lower traffic, so we have generally got away
> with doing our Red Hat builds and TCK testing, and then just doing the final
> push & release in public. The process will need to be formalised for 8u & 11u.

It's too late to run TCK and other suites by the time the release is 
about to happen to have a healthy release (yet, I'm not suggesting such 
a procedure should not happen in the end). It has to be an on-going 
process, and a repository where functional and regression fixes are 
accumulating is going to help with that, since this is the repository 
where changes most likely to cause regressions will happen.

As far as TCK is concerned, it's binaries that are certified, and there 
is a thousand ways to produce a binary that won't pass TCK from the 
sources someone else uses to produce a good one.

I believe companies willing to participate in this effort are mostly 
represented here and the process should be just continuous testing and 
bug fixing. From BellSoft end, we are willing to participate focusing on 
some platforms which are less covered by others, such as ARM32, some 
AARCH64 microarchitectures, Solaris SPARC and x86. I believe the rest 
are better covered by other companies testing (SAP, Red Hat). I'm not 
suggesting there should not be some overlap.