Moving to GitHub (project Skara)
Marcus Hirt
marcus.hirt at datadoghq.com
Mon Sep 9 10:38:27 UTC 2019
(Replying so that Erik, who just joined the mailing list, can easily
join the discussion thread.)
On Fri, Sep 6, 2019 at 3:29 PM Mario Torre <neugens at redhat.com> wrote:
>
> 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