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

[Andrew Haley]

On 25/02/2021 05:01, Andrew Hughes wrote:
> 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?

Who's rushing? All we're doing right now is talking.

>>> 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>
>
> Since when is Mercurial obsolete? Looking at its Wikipedia page, it
> seems to have had a new release more recently than OpenJDK!

It's very slow and doesn't scale well, and is rapidly losing out to
Git. Its maintainers may heroically try to keep it going, but it's
obsolescent now and will be obsolete some time during the life of
OpenJDK 8.

> 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 thinking of a contributor who wants to push a bug fix through to
all supported versions of OpenJDK. I don't want to put roadblocks in
their way. I very much expect that anyone who joins OpenJDK today will
*never* use Mercurial, for anything. This means that they'll either
need a proxy to push their patch to 8u or it simply won't get fixed.

> I'm much more concerned about the disruption a change would cause to
> those who already contribute to 8u.

That's a general-purpose argument against any change, even one that is
in the long (or even medium) term beneficial. But Skara has proved to
be a huge improvement in workflow across all of OpenJDK active
development, such that it makes no sense to starve 8u forever of its
benefits. Now, it doesn't work so well with backports; they have not
been Skara's primary goal, that is true. But Skara development is
moving fast, and I expect there will be a good backport process soon.

> 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.

Maybe, but I doubt it.

> 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.

Having many individual forks is the GitHub way of working. It works
well, IMO better than multiple branches would, but that's another
discussion.

> 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.

OK. So let's do that to start with, and see how it goes. We don't have
to use the Skara tooling if we don't want to.

-- 
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