Call for Discussion: New Project: Skara -- investigating source code management options for the JDK sources

[Andrew Dinn]

On 28/07/18 20:11, Patrick Reinhart wrote:
> I’ve now contributed a couple of changes to the JDK now and for me as
> a part time contributor. It would be much easier for me, to have used
> git instead of mercurial, due the fact that I use git on a daily
> basis. and its commands for creating different feature branches and
> handling patches would be easier for me.

Well, I am in the fortunate position of using both hg and git regularly
and I don't actually think there is much of an edge to either in terms
of usability or, indeed, functionality. For the things you need to do
everyday both work reasonable well and are fairly easy to learn and
retain. I do actually have a preference but I don't think it matters
much (any decision to move really must not be reduced to a beauty contest).

If there is a reason to move then I think it is neither function nor
usability but the issue Joe raised -- performance i.e. the way they both
scale. The hg repo for OpenJDK has become very unwieldy. Without
shipilev.net it would already be a big headache (thank you, Aleksey!).
It appears from Joe's research that git is currently, and will continue
to be, much more manageable in this regard. Whether that is enough to
justify a change is a hard question to answer but I can understand his
argument and sympathise with it.

> Nevertheless I it is important in my opinion that git and the Github
> process are two separate things. I would fear to have the JDK on
> Github just due to the fact you might get flooded with a huge amount
> of pull requests for things not actually discussed on any mailing
> list before and the existing reviewers would not be able to keep up.

There are many virtues to our current multiple mailing list-based review
model which need to be thought about carefully before we make any
change. Moving to something like Github (even if it is not Github
itself) is not something we ought to do lightly. However, that is a
completely different order of change to switching the SCM system we use.

> I would like to see a improvement and better support in handling
> contributions and the review process in general as using the webrev
> tool as it is now. In that regard the review process on github using
> a separate feature branch on a clone seems a good start...
Maybe. I am not sure from my experience on Graal that this is
necessarily the best way to do things. One of the benefits of our use of
email lists is that you /have/ to subscribe and get sent a copy of
everything that is happening in the area you wish to contribute to
(sometimes even several lists in several areas). That does mean the
initial experience is like trying to drink from a firehose but that is a
good thing as well as a bad one. It's important to know what is going on
in the project if you are going to be contributing to it to any
significant degree. So, while the volume of traffic makes it hard for
people to get started it means that those who do start are aware of what
they will need to keep up with in order to continue. I don't believe the
project is actually going to benefit from bringing in contributors who
quickly drop out again. Yes, we might get a lot of small low-priority
fixes but at what overhead?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander