[11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle

[Andrew Hughes]

On 18:52 Fri 12 Feb     , Andrew Haley wrote:
> On 12/02/2021 07:15, Andrew Hughes wrote:
> > even been released yet. Why the rush?
> > 
> > I don't see any reason at all to start altering 8u at such a late
> > stage in its development.  All risk and no gain.
> > 
> > [0] https://github.com/openjdk/jdk/pull/2153#issuecomment-766960241
> 
> We've always been a bit short of boots on the ground, and being
> stuck on an obsolete VCS will only isolate 8u even more. Maybe this
> is an optimist-versus-pessimist thing, but 8u may be about halfway
> through its lifetime! <ducks>
> 
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 

Since when is Mercurial obsolete? Looking at its Wikipedia page, it
seems to have had a new release more recently than OpenJDK!

Are there people who want to contribute to 8u, but are being prevented
by the choice of version control system? It seems unlikely to me. I'm
much more concerned about the disruption a change would cause to
those who already contribute to 8u.

That goes further than just developers active on this mailing list. It
includes many people testing it and distributing it via various
channels. Over the course of the last week, I've had to redirect two
IcedTea bugs that will filed for IcedTea-Web, which moved to a git
repository elsewhere some time ago, and take over our update to 16u,
which was initially pointing at the last Mercurial sources, which
apparently are still around to cause confusion. In short, it takes
time for such changes to filter to all concerned and the impact
is more extensive than it may initially appear.

There are really two issues here. The first is the choice of version
control system.  As one of the people who has to do more with the
repositories than just pushing my own patches, I'm probably more aware
of the failings of Mercurial than some. In particular, 11u's use of a
mono repository is painfully slow in Mercurial. 8u, on the other hand,
would likely be slower as a git mono repository than the current
individual Mercurial repositories.  However, I don't see the great
rush to switch to git.  The potential disruption that would cause
seems greater than the pains of Mercurial.

What baffles me about OpenJDK's use of git is why the main advantage
of branches hasn't been used, and update repositories are being
created as separate trees as before. The obvious advantage of using
git to me would be to have one repository with multiple branches and
thus fewer things to check out.

However, as someone who already uses git for other projects, I wouldn't
have a problem with our repositories using it; my concern there is more
for the impact downstream and on those not familiar with git. My much
greater concern is we don't seem to be apply to just switch VCS, but
have to adopt a completely different set of processes as well, which
are frankly more confusing, less trustworthy and still seem to be
heavily in development.

If we could just switch to git without this SKARA thing, I'd be
much less concerned. As it stands, SKARA has not yet even been
used to produce a new OpenJDK release, yet there seems to be
some bizarre rush to use it on production update releases. I
really don't understand this and I've put off even replying
to this thread because it's making me quite angry.

Are we expecting all the Mercurial trees to vanish by the end
of the year? I can't otherwise see why we need to jump on this
so quickly.

Reading other comments on this thread, it seems backporting support
isn't yet ready in SKARA. If so, why are we even considering switching
to it so soon? My own experience is that I still have a bug pending
to backport to 13u & 16u and no idea how to do it. Pushing it to 11u
was trivial. Why do we want to make lives harder for ourselves?
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222