Moving to GitHub (project Skara)

[Marcus Hirt]

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. IMHO it's rather easy and painless, and comes with a lot
of advantages. For JMC, the move would mean that the need for setting
up a webrev script, generating the webrev, rsyncing it to a folder
(with versioning done by folder name) goes away. The need to then
compose a properly formatted e-mail, link to the webrev and then send
it out to the mailing list goes away.

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. Also, awesomely enough, the project can start
using GitHub integrations like CI infrastructure to have tests run
before allowing to merge etc.

Kind regards,
Marcus

On Fri, Sep 6, 2019 at 1:07 PM Mario Torre <neugens at redhat.com> wrote:
>
> On 03/09/2019 18:16, Marcus Hirt wrote:
> > Sure. Tuning the process as we go will certainly be possible and
> > likely necessary. That said, we should, of course, discuss the initial
> > settings to avoid as much later grief as possible.
> >
> > These are some of the things I am considering for the process:
> > 1. Reviews are required. One reviewer or two committers.
> > 2. A bug ID will be required for each change (let's discuss if you are
> > of a different opinion).
> > 3. Notifications for pushed commits will be sent to jmc-dev.
> > 4. Pull requests will be mirrored to jmc-dev.
>
> I think #4 is where I'm a bit worried. While I think it makes sense for
> people to use the usual github workflow if they want to, one key point
> of project Skara was the promise that we didn't have to think about it.
>
> For JMC that may not be so important, but it will be paramount for
> OpenJDK, so we should play the same game with the same rules.
>
> I fear the enforcement to create forks and branches for each and every
> commit may be overkill, especially when you already work on four or five
> different project versions at the same time, and currently github
> doesn't allow to simply clone, create a patch and send it to list for
> discussion, it forces you to use the browser interface with a multi-step
> approach where you first fork, then patch, then commit and then manually
> go over github to create the pull request. It's overkill.
>
> So before we commit to this, I need to fully understand to what extent
> the workflow will change from the current one.
>
> Again, I'm well aware that JMC may adapt more easily given the overall
> linearity of the project, but the reason why we would be early adopters
> is to test and try out skara for OpenJDK, so we need to be sure our work
> will translate to a smoother experience for OpenJDK as for JMC.
>
> Cheers,
> Mario
>
> > Kind regards,
> > Marcus
> >
> > On Tue, Sep 3, 2019 at 5:53 PM Mario Torre <neugens at redhat.com> wrote:
> >>
> >> On 30/08/2019 13:43, Klara Ward wrote:
> >>> +1 for GitHub
> >>
> >> I'm a bit skeptical to be honest, we should first define what the new
> >> process will be before buying the new and shiny.
> >>
> >> For instance, it's my understanding that we want to get rid of webrevs
> >> and only use github pull requests, however that would put us in a
> >> situation where jmc is different from the other openjdk projects. Emails
> >> also give us a great overview of what the project is doing, I'm afraid
> >> github will hide most of this making more difficult to reconstruct the
> >> history and evolution of the project.
> >>
> >> Of course, I do like some aspect, for a reviewer a pull request is
> >> probably a great way to know a review is necessary, so I don't want to
> >> just rule out this move entirely.
> >>
> >> From my team the consensus was that before moving to github we should
> >> have a very clearly defined process and stick with it.
> >>
> >> I would personally add that it would be best to not be among the early
> >> adopters, and rather follow what the rest of the openjdk projects do, in
> >> particular openjdk itself, since we have such a close dependency on it
> >> and we are citizens of the same organisation.
> >>
> >> 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
>
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898