Moving to GitHub (project Skara)

[Mario Torre]

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