Moving to GitHub (project Skara)

Mario Torre neugens at redhat.com
Fri Sep 6 13:29:40 UTC 2019


On 06/09/2019 14:56, Marcus Hirt wrote:
> Hi Mario,
> 
> The normal way to do this is to have one fork that you work in, for
> all your PRs. Branching is a very quick operation, and anyone involved
> in open source projects on GitHub will already know this workflow
> intimately.

Branching may be quick, but maintaing a fork isn't simple. Also 80% of
the work we do is based on fixing short lived issues, the remaining 20%
involves significant work, that may already happen in a forked
repository. The difference here is between being forced the overhead of
maintaining a fork and the external steps of using the web interface to
submit and merge the work done on each forked repository, with the
occasional need to have one. It's fine to keep those as option for
people who want them, but we shouldn't be all forced to adapt.

I'm not very happy to change to the dictation of another tooling imposed
workflow to be honest.

> Other advantages include using an environment known to most developers
> out there - an environment not requiring any OpenJDK special scripts
> or workflows (easy on-boarding of new developers), contributors
> getting recognition where it matters (many companies/recruiters go
> look at GitHub commit history), starting using git (hg tool support is
> starting to wane) etc.

Well, except that we are already OpenJDK developers, so we already know
all the tooling and workflow. It's exactly why I resist the GitHub way,
it may be nice for some but not for all.

Maintaining versions of webrevs is indeed a problem, but the process of
creating them is trivial and can be done via command line from the same
location you do the coding work, i.e. I don't need to
clone/fork/merge/remember to merge with a different repository too/then
open the browser click around until I find the right place and create a
pull request. If you use rsync you don't even need to create versions,
just keep overriding the same location.

> Also, awesomely enough, the project can start
> using GitHub integrations like CI infrastructure to have tests run
> before allowing to merge etc.

We already have most of this infrastructure in place, so if anything we
would need to spend time and resources to adapt it.

Cheers,
Mario


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


More information about the jmc-dev mailing list