Migrating D-Bus to GitLab

[Simon McVittie]

On Sat, 13 Oct 2018 at 12:08:48 +0200, Ralf Habacker wrote:
> 3. https://gitlab.freedesktop.org/dbus/dbus/blob/master/CONTRIBUTING
> seems to be outdated

I'm going to try to update that early this week. My intention
is to make it similar to the version I pushed to dbus-glib
(although obviously without the warnings about deprecation):
<https://gitlab.freedesktop.org/dbus/dbus-glib/blob/master/CONTRIBUTING.md>

I'll cc you on the merge request.

I suggest you visit https://gitlab.freedesktop.org/dbus/dbus/forks/new
and create a fork for your dbus changes - that's what I did for
<https://gitlab.freedesktop.org/dbus/dbus/merge_requests/1>, and it
means changes from maintainers mostly go through the same workflow as
changes from everyone else.

> 1. patches have a bug reference e..g  "Bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=104022". Should this be
> replaced now with "Bug:
> https://gitlab.freedesktop.org/dbus/dbus/issues/193" or something else ?

If the patch *resolves* the bug (as in: accepting the patch and any patches
it depends on will make the bug go away completely) then you can use one of
these, and Gitlab will know to close the bug automatically when the patch is
accepted or cherry-picked:

    Fixes: https://gitlab.freedesktop.org/dbus/dbus/issues/193
    Resolves: https://gitlab.freedesktop.org/dbus/dbus/issues/193
    Closes: https://gitlab.freedesktop.org/dbus/dbus/issues/193

See https://docs.gitlab.com/ee/user/project/issues/automatic_issue_closing.html
for full details.

If the patch is *related to* the bug but is not sufficient to resolve it,
please use something that won't match the issue-closing pattern, like
"Bug: https://gitlab.freedesktop.org/dbus/dbus/issues/193".  Old Bugzilla
URLs are also OK for this use.

Either way I'd like to keep using the full URLs, not just "Fixes: #193".

If you have a series of patches that all contribute a small amount to
closing an issue, but you can't really point to one of them and say
"*this* is the commit that fixes it", then you can use "Bug: ..." on all
of them, and put "Fixes: #193" in the text of the merge request instead
- this means that none of the patches fix the issue on their own, but
accepting the whole merge request does.

> 2. patches were uploaded to the related bug e.g.
> https://bugs.freedesktop.org/attachment.cgi?id=136077. Should they now
> appended to the related gitlab issue and/or opens a merge request  with
> a pointer to the issue

If you think they're ready to merge, please open a merge request.

If they're ready for further testing/comment but not ready for merge,
open a merge request and make sure the title starts with "WIP:".

In general each merge request can only be accepted or rejected as a whole,
so if some parts of a merge request are more controversial than others,
it might make sense to have multiple merge requests for one issue.
For instance, the patch attached to
https://gitlab.freedesktop.org/dbus/dbus/issues/193#note_48189
could probably be applied even if we're not sure about the rest of the
issue, since it doesn't actually have much to do with Android.

(And yes, I realise
https://gitlab.freedesktop.org/dbus/dbus/merge_requests/1 is too big -
I'm going to break out some individual fixes from it so we can consider
fast-tracking them in.)

> 3. gitlab cli (https://python-gitlab.readthedocs.io/en/stable/cli.html)
> may be usable as git bz relacement (not checked yet)

This is less important for Gitlab than for Bugzilla anyway, because if
you just `git push` to any fork of dbus, you'll be given a URL to visit
to create a merge request, and the steps you have to do in the web UI
are per merge request, not per patch - you don't have to attach patches
individually.

    smcv