Gitlab transition roadmap

[Alexandre Julliard]

Folks,

Here's my current roadmap for the transition to Gitlab. Feedback and
help are welcome. In particular, it would be nice if people would
volunteer to update the documentation, I'm no good at that.

- Make gitlab.winehq.org the canonical git repository, setup mirroring
  to source.winehq.org.

- Refine behavior of mailing list gateway, possibly send output to
  separate list.

- Update Wiki documentation (SubmittingPatches etc.), define signoff
  policy, document the new workflow.

- Implement bot to automatically assign reviewers based on the
  MAINTAINERS file.

- Make testbot work directly from MRs instead of mailing list
  patches. Integrate test reports with Gitlab CI.

- Import Gitlab sources and build our own version, to enable making
  changes to the code.

- Work with respective maintainers to plan if/when/how to move other
  Wine projects to Gitlab:
  - tools (done)
  - website (done)
  - wine-gecko (done)
  - wine-mono
  - wine-staging
  - vkd3d
  - appdb
  - bugzilla
  - fontforge

- Require MRs for all patches, retire the source.winehq.org/patches
  tracker (direct links to old patches must of course be preserved).

- Retire the gitweb browser, redirect to Gitlab.

- Investigate moving the Wiki to Gitlab.

- Investigate switching to the Gitlab bug tracker.

[Esme Povirk (she/they)]

On Wed, Jun 15, 2022 at 7:08 AM Alexandre Julliard  wrote:
> - wine-mono

I've been thinking about this and my primary requirement is CI. I want
a test run for MRs and pushes to the develop branch, at least on
Linux, ideally on Windows too.

I'd probably convert my github repos to mirrors of winehq once we're
ported over, and I'd use my own personal repos on winehq gitlab for
WIP stuff and my own MRs. I'd still want CI on the github mirror as an
extra check and to make sure macOS continues to work. I would probably
continue to accept github PRs.

There are also a lot of submodules that need to be ported over. Some
of them point to upstreams, should we mirror those on winehq just in
case?

[Gabriel Ivăncescu]

Hi,

Just a couple requests if I may.

On 15/06/2022 15:08, Alexandre Julliard wrote:
> - Refine behavior of mailing list gateway, possibly send output to
>  separate list.

I don't mind a separate list or anything else, but please keep a way for 
some of us to still be able to check the "patch flow" like now via 
email. I don't mind if it this requires tinkering on my end as long as 
it's "possible"...
> - Work with respective maintainers to plan if/when/how to move other
>  Wine projects to Gitlab:
> - tools (done)
> - website (done)
> - wine-gecko (done)
> - wine-mono
> - wine-staging
> - vkd3d
> - appdb
> - bugzilla
> - fontforge

For bugzilla I'd rather prefer if it remained because, well, it works 
without javascript and is simple and lightweight... I don't mind web UIs 
if they're simple but gitlab overall leaves a lot to be desired.
> - Retire the gitweb browser, redirect to Gitlab.

As above, is it too much hassle to keep this around? Even if it's just a 
mirror. I like that it's simple and lightweight and can be browsed 
easily, gitlab is way too bloated both in design and accessing it, and 
doesn't work without javascript either.

I have to admit when I first saw the gitlab experiment, I didn't expect 
a total overhaul like this even for stuff not related to patches, I 
thought it would be optional.

Just my 2 cents.

[Zebediah Figura]

On 6/16/22 11:22, Gabriel Ivăncescu wrote:
> > - Work with respective maintainers to plan if/when/how to move other
> >
> > Wine projects to Gitlab:
> >    - tools (done)
> >    - website (done)
> >    - wine-gecko (done)
> >    - wine-mono
> >    - wine-staging
> >    - vkd3d
> >    - appdb
> >    - bugzilla
> >    - fontforge
>
> For bugzilla I'd rather prefer if it remained because, well, it works 
> without javascript and is simple and lightweight... I don't mind web UIs 
> if they're simple but gitlab overall leaves a lot to be desired.

Yes, I agree. Gitlab's UI in general is pretty awful, and I'd hate to 
have to use it for bug tracking. And while command line API tools are 
fine for merge requests, and the same tools can access the bug tracker, 
they aren't sufficient for reading structured data.
> > - Retire the gitweb browser, redirect to Gitlab.
>
> As above, is it too much hassle to keep this around? Even if it's just a 
> mirror. I like that it's simple and lightweight and can be browsed 
> easily, gitlab is way too bloated both in design and accessing it, and 
> doesn't work without javascript either.
>
> I have to admit when I first saw the gitlab experiment, I didn't expect 
> a total overhaul like this even for stuff not related to patches, I 
> thought it would be optional.
>
> Just my 2 cents.

Yes, agreed wholeheartedly. Can we please keep this around?

[Zebediah Figura]

On 6/15/22 07:08, Alexandre Julliard wrote:
> - Work with respective maintainers to plan if/when/how to move other
>  Wine projects to Gitlab:
> - tools (done)
> - website (done)
> - wine-gecko (done)
> - wine-mono
> - wine-staging
> - vkd3d
> - appdb
> - bugzilla
> - fontforge

FWIW, we'd be glad to move wine-staging to winehq.org.

One thing to note, though, is that we've been taking advantage of 
GitHub's free build service to test building Wine (we don't run the 
tests, just verify it builds) on Mac OS, which we'd lose if we move to 
winehq.org. That said, we could easily set up a script to mirror commits 
back to GitHub, and I think we also want to be able to set up a testbot 
machine to test builds for Wine itself (bug 49729).

ἔρρωσθε,
Zeb

[Gijs Vermeulen]

Op wo 15 jun. 2022 om 14:08 schreef Alexandre Julliard <[e-mail]
> :
> - Investigate switching to the Gitlab bug tracker.

I just wanted to quickly chime in here and say that I would not be in favor
of this. I find gitlab's tagging, searching and other bug administration
tools to be lacking compared to bugzilla's.
Making sure bug reports are high in quality is already not an easy task for
wine and I fear switching to gitlab issues would make it harder instead of
easier.

Kind regards,
Gijs