New candidate JEP: 369: Migrate to GitHub

[Dell Green]

I'm sure many of us contribute to many open source projects. Tying dedication to a project to the learning of mercurial doesn't factor in that  everyone has priorities, and these priorities are not necessarily to invest in the learning of an SCM that none of your other projects use, especially if someone else is paying for your time.

Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: discuss <discuss-bounces at openjdk.java.net> on behalf of discuss-request at openjdk.java.net <discuss-request at openjdk.java.net>
Sent: Sunday, November 17, 2019 12:00:19 PM
To: discuss at openjdk.java.net <discuss at openjdk.java.net>
Subject: discuss Digest, Vol 151, Issue 15

Send discuss mailing list submissions to
        discuss at openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
        https://mail.openjdk.java.net/mailman/listinfo/discuss
or, via email, send a message with subject or body 'help' to
        discuss-request at openjdk.java.net

You can reach the person managing the list at
        discuss-owner at openjdk.java.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of discuss digest..."


Today's Topics:

   1. Re: New candidate JEP: 369: Migrate to GitHub ? Eating your
      own dog food? (Franti?ek Ku?era)
   2. Re: New candidate JEP: 369: Migrate to GitHub (Johan Vos)
   3. Re: New candidate JEP: 369: Migrate to GitHub (Joe Darcy)


----------------------------------------------------------------------

Message: 1
Date: Sat, 16 Nov 2019 15:41:58 +0100
From: Franti?ek Ku?era <franta-java at frantovo.cz>
To: discuss at openjdk.java.net
Subject: Re: New candidate JEP: 369: Migrate to GitHub ? Eating your
        own dog food?
Message-ID: <a41034c5-78f1-a61f-2520-445bb8aad96f at frantovo.cz>
Content-Type: text/plain; charset=utf-8

Dne 13. 11. 19 v 15:15 Thomas St?fe napsal(a):
> So, this is also an assumption - that the tool chain keeps working and that
> the effort spent maintaining it is less than the effort spent today on
> maintaining the old infrastructure (which to be fair is done by Oracle
> alone).

A classic quote: ?There is nothing more expensive than something free?.
Why should we expect that anyone is willing to reduce Oracle's costs by
providing a service for free or cheaply? Of course, there are economies
of scale, but Oracle or OpenJDK itself are quite big and there are much
smaller teams or even individuals who run own source code repositories
on their own servers.

Another thing that is unclear to me: how is Oracle going to offer and
sell their cloud services like ?Streamline Team Development and Software
Delivery?
<https://www.oracle.com/application-development/cloud-services/developer-service/>
(that include Version Management ? Git repositories) to the customers,
while not providing the hosting service to their own projects like OpenJDK.

The centralization of more and more projects under a single
provider/corporation (GitHub) is IMHO not a good way to develop
software. Especially in the long term. And if we talk about comfort and
attractiveness for random contributors ? what about open standards (e.g.
for single-sign-on)? Are not they a better way than centralizing
everything under a single provider/company?

Franta



------------------------------

Message: 2
Date: Sat, 16 Nov 2019 19:28:26 +0100
From: Johan Vos <johan at lodgon.com>
To: discuss at openjdk.java.net
Subject: Re: New candidate JEP: 369: Migrate to GitHub
Message-ID:
        <CAK7C+XjR0L8toysdS-f=C8-P=Yn9TimeBbDGB1hLY+Z45S6+1g at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

I've had the privilege to work with the Skara tools in both the OpenJDK
Mobile and the OpenJFX projects.
Having read most of the comments in this thread, there are a few things
that I would like to add.

The quality of a project like OpenJDK highly depends on the committers. If
we want to maintain the current high quality, it is important that the
current committers, who are responsible for this quality, are ok with
changes in the process. My observation during the OpenJDK Committers'
Workshops is that most committers are ok. However, it's very important to
take into account the critics from committers who do not like this JEP.

>From what I've read so far, and from my experience dealing with the Skara
team, I personally don't see real showstoppers.
One of the things I really like about the Skara approach is the automatic
creation of an RFR mail and the creation of a webrev. That already saved me
lots of time in the OpenJFX project, time that I could contribute to write
code or review PR's. More automation, less chances for typo's are a great
thing. I like the guidelines of the bot and the flow is very intuitive. I
can choose to work via the web interface or via the CLI.

Yes, the GitHub web interface is by no means a 100% match of the email
approach, and I don't hide it that I'm not a big fan of the
"Web-everywhere-for-everything" approach, on the contrary.
However, comparing other github projects I work on with the Skara-based
projects I work on, I really like the Skara approach. Thanks to the Skara
tools, the dependency on web-based control flow is much lower. And most
important, the Skara tools are open source and can be discussed and
improved.

I honestly don't know what the best approach is for discussing PR's. As
stated in other replies, the conversation-tab in the GitHub PR's has its
limitations, but it has also stated correctly that email discussions have
limitations and can create confusion as well.

Looking at the alternatives in the JEP, there is nothing that comes close
to the current proposal. While I don't think there will immediately be a
large number of high-quality new contributors simply because of the move to
github, I am convinced the barrier becomes lower. Moreover, the github
approach makes it easier for developers who depend on the JDK to examine
the code if needed. I often run into issues with third party software, and
when I can easily find the code on github, it makes it much easier to
understand, appreciate, or even help. Having to browse through the hg web
interface, or download the whole JDK project, is not really inviting.

As I stated in the beginning, the high quality of OpenJDK is mainly
achieved because of the real smart committers behind it (and the companies
paying them), and the high-quality code committed and reviewed by those.
There are not many software projects that can celebrate their 25th birthday
like this. Committers write code, and use infrastructure to collaborate.
Infrastructure evolves. I've been a happy mercurial user for a long time,
and gradually moved to git and mainly github over the past years. None of
the bottlenecks I ran into have been due to github. As long as the quality
bar is not lowered, I'm ok with changes in infrastructure.

- Johan

Op di 12 nov. 2019 om 17:02 schreef <mark.reinhold at oracle.com>:

> https://openjdk.java.net/jeps/369
>
> - Mark
>


------------------------------

Message: 3
Date: Sat, 16 Nov 2019 12:38:20 -0800
From: Joe Darcy <joe.darcy at oracle.com>
To: Mario Torre <neugens.limasoftware at gmail.com>, Stephen Colebourne
        <scolebourne at joda.org>
Cc: discuss <discuss at openjdk.java.net>
Subject: Re: New candidate JEP: 369: Migrate to GitHub
Message-ID: <98b61755-e1eb-62cd-d84d-ec4667f316af at oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Hello,

A sentiment that has been expressed several times on this thread is "If
someone is dedicated enough to the JDK, they'll just learn to use
Mercurial." This can easily go in the other direction; if the JDK moves
to Git on a hosting provider, "If someone is dedicated enough to the
JDK, they'll just learn to use Git on a hosting provider." As Git is
currently the most widely-used SCM and GitHub a common hosting provider,
many people may have very little to learn.

As has been attested to several times on this thread, there are at least
several experienced developers who have been put off from contributing
to the JDK because of the SCM situation. My sense is that many
developers feel the JDK's continued use of Mercurial is retrograde and
that a move to Git on a hosting provider is already years overdue. I
think postponing consideration of a migration another year, two years,
(five years?, ten years?) would be harmful to the health of the overall
JDK effort.

Any SCM move has the potential to be disruptive, but such a move should
be approached with care rather than timidity.

-Joe


On 11/15/2019 2:37 AM, Mario Torre wrote:
> Il giorno ven 15 nov 2019 alle ore 11:17 Stephen Colebourne
> <scolebourne at joda.org> ha scritto:
>> Just to note that I remain hugely supportive of this. GitHub's
>> community interaction facilities have been very positive to use from
>> my perspective, and I've never regretted moving to git or GitHub. With
>> automated testing of patches, it will represent a step change in the
>> ability to interact with the project.
> You don't need GitHub and its workflow to have have automated testing
> of patches, for instance it's nevertheless a good idea to extend the
> hotspot submit repo to cover any patch.
>
> In all those discussions we've always seen some form of "this will
> improve because X and Y" but overall those X and Y are actually
> independent from the move to GitHub and the new imposed workflow and
> never address the one and most important issue, the overhead of
> adapting to a completely new workflow and in particular that of the
> pull-request/public fork approach. I think the JEP should extensively
> prove why the change is significantly better than the status quo so
> that this change is worth, it feels to me that the situation is
> reversed here.
>
> Btw, I'll be very happy to host a discussion about this more during
> FOSDEM and have an actual confrontation, perhaps it's even a better
> idea to discuss this during the Committer's Workshop (assuming there
> will be one in February), but so far what I see is that this
> discussion is a bit stalled.
>
> In my previous email I jokingly said (and perhaps it wasn't really
> really clear I meant it like "good try Mario") to wait one or two
> years for this to settle, but I'm very convinced that we really need
> to give more time to the projects that were currently moved to GitHub
> to see if the additional hassle and the workflow change (including the
> time and resources needed to adjust the tools and the general
> ecosystem) is actually really that valuable: this JEP is premature.
>
> Cheers,
> Mario
>


End of discuss Digest, Vol 151, Issue 15
****************************************