RFD: Draft guidelines for working on jdk8u

[Langer, Christoph]

Hi Andrew,

> > > I think jdk8u-dev -> jdk8u syncs need to be done at more regular
> intervals
> > > with jdk8ux-by style tags.
> >
> > As per my last mail in jdk-updates-dev [1], I think there should be exactly
> one sync jdk8u-dev->jdk8u per quarterly release (e.g. RDP2)
> >
> > But the other way round (jdk8u->jdk8u-dev), we should have regular
> syncs.
> 
> But what is being synced from jdk8u->jdk8u-dev?
> This seems to be suggesting that they are developed separately for a long
> period of time. It also seems to be pretty risky to put changes directly
> into jdk8u first before they have soaked in jdk8u-dev.

Well, how long separate development occurs is something that we can decide. Oracle creates release branches quite soon after a CPU has been shipped. We can branch later.

Generally, I don't think we should see lots of changes in the stabilization repository. We have to restrict activity to real P1 issues, cherry-picks of changes that Oracle has picked into their equivalent CPU update and test fixes. Apart from the Oracle replays, which we'll have to do, all other changes in the stabilization repository shall only fix things and not bear high risk of introducing regressions.

> > > Once a quarter, we will snapshot the jdk8u tree and prepare a Critical
> > > Patch Update (CPU) release. Once the snapshot has been taken the
> > > engineers working on the CPU will work in the dark, sharing the
> > > patches with only the OpenJDK Vulnerability Group. Any patches not
> > > committed to jdk8u at the time of the snapshot will probably have to
> > > wait for a later release. [ I don't propose to make any non-CPU
> > > releases: one release a quarter should be quite enough for
> > > jdk8u. However, if an urgent problem arises we might need to make an
> > > intermediate release. ]
> >
> > I'd rather prefer if the repository in the dark will regularly be refreshed
> from jdk8u and at the end of the CPU release be merged back to the open.
> 
> I don't think that's practical. Those working on the CPU have enough work
> to do with backporting and testing without having to continually do
> integration
> work from jdk8u. It should be frozen at the time the snapshot is taken and
> only
> explicit exceptions pushed after that point.

The stabilization repository will always be virtually frozen. Only explicit exceptions of the types I have named above will ever be allowed in the release repository. So I would not expect too much of integration issues. You can also start considerably later with the CPU compared to the time of the fork from dev to stabilization.

Best regards
Christoph