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

[Erik Osterlund]

Hi,

For me the main advantage of switching to git is tooling support. I already switched to using git locally with an hg remote (that I got from our Skara friends), so that I can use magit in Emacs, and it has made my life much easier compared to using mq patch queues with poor Emacs integration that forced me to make my own extensions to make me less sad. These days I am much happier and more productive using git, despite having to move things over to hg before pushing. It is worth it for me to be able to use magit.

Considering every hotspot engineer seems to have their own unique quirky development environment, it might be that better and wider tooling in general matters to more people than myself. It certainly matters to me anyway.

/Erik

> On 30 Jul 2018, at 10:47, Andrew Dinn <adinn at redhat.com> wrote:
> 
>> 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