8u/11u repo access and Jira changes
shade at redhat.com
Tue Feb 26 19:57:27 UTC 2019
On 2/26/19 8:41 PM, Langer, Christoph wrote:
> - Look at how it works with the jdk/jdk12 repositories for upstream development. There, jdk12 got more and more restrictions applied and in fact it's virtually closed now at release candidate phase. But the repository is not closed, theoretically everybody could push
Yes, and jdk/jdk12 is the interesting example.
First, jdk/jdk12 is really a separate repository that you would not have on your machine, unless you
had the intent to push to jdk12 at least once. The majority of committers don't, which makes the
mistakes less frequent. It is one of the very good process moves to have jdk/jdk that is always
catch-all, and any stabilization forests fork off separately, requiring separate action to work with
it. Note it is exactly the opposite of jdk-updates/jdk11u and jdk-updates/jdk11u-dev situation: most
people have the _wrong_ repository locally.
Second, people (experienced people!) who have both jdk/jdk and jdk/jdk12 trees routinely mix them up
and push the change designated to one repository, into the other one. I did it at least once. People
around me did it at least twice. The saving grace there is pushing to "wrong" repository does not
require the backout there, so these mistakes are rectified cleanly.
> - If somebody pushes by mistake to the non dev repository, this can always be backouted
Right. Do we know how hgupdater and backports backouts work? Do we really want to test it during the
maintainership takeover? Do we need to modify reports to avoid backouted backports too?
More information about the jdk8u-dev