Bug 93283

(In reply to Ralf Habacker from comment #0)
> 2015
> - Performing static code analysis using coverity (bug 90021)

- Start of continuous integration service (Travis CI)

For the reference: mediawiki has moved to phabricator too and has also migrated their bugzilla instance data into phabricator https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla#Bugzilla_data_migrated

What’s the intention behind this bug report? To discuss the advantages/disadvantages of moving to phabricator.freedesktop.org?

(In reply to Philip Withnall from comment #3)
> What’s the intention behind this bug report? To discuss the
> advantages/disadvantages of moving to phabricator.freedesktop.org?

I'm honestly not sure, and I'm tempted to close it as NOTABUG. I think a mailing list thread would probably be more appropriate for this.

My opinion on Phabricator, though:

I would very much like D-Bus (including its reference implementation dbus) to be a follower, not a leader, in terms of where and how it's hosted. As a mature project whose maintainers all have other responsibilities, we should be careful how we spend our innovation tokens[1] - I want to spend my limited D-Bus time on fixing D-Bus, not on fighting with versions or configurations of Phabricator that aren't necessarily mature yet.

At some point in the future, perhaps Phabricator will be the boring, predictable choice for freedesktop projects, with reasonably well-known workflows - *then* it will be appropriate to move onto it.

Analogously, we didn't move to git until git was already a boring choice - which is good, because it means we didn't move to something that initially looked attractive but then turned out to be a bad idea, like Darcs or Monotone. Similarly, we're still using Autotools (and secondarily CMake), not the latest build-system hotness, which means we've successfully avoided things like Waf and SCons. (Remember those?)

[1] http://mcfunley.com/choose-boring-technology

(In reply to Philip Withnall from comment #3)
> What’s the intention behind this bug report? To discuss the
> advantages/disadvantages of moving to phabricator.freedesktop.org?

yes, here a few details: 

As an outside gnome develop I find it partially very hard to deal with patchsets in recent bugzilla, expecially with updating patches and tracking reviews. On the command line there is git-bz, which made my experience partially better but it does not fit very well in the way patches are handled by dbus (for example git-bz attach does not allow to add additional text in the created bug tracker comment, wich creates empty comments with only a patch appended) and lacks to deal with patch sets (superseeded patches are not automatically be set as obsolated, so manual intervention is required). 

As freedesktop.org came up with phabricator they introducted Arcanist too, the command line patch manager, which looked to me as a way to improve things in this area especially for non-every-day-dbus-hacker.

(In reply to Ralf Habacker from comment #5)
> for example git-bz attach does not allow to add additional
> text in the created bug tracker comment

Write it as the commit message body.

> As freedesktop.org came up with phabricator they introducted Arcanist too,
> the command line patch manager, which looked to me as a way to improve
> things in this area especially for non-every-day-dbus-hacker.

git-phab is a whole lot nicer to use (for my workflow, at least) than arc.

https://phabricator.freedesktop.org/tag/git-phab/

(In reply to Philip Withnall from comment #6)
> (In reply to Ralf Habacker from comment #5)
> > for example git-bz attach does not allow to add additional
> > text in the created bug tracker comment
> 
> Write it as the commit message body.
This example https://bugs.freedesktop.org/show_bug.cgi?id=97357#c47 shows the need to have message only added to the bug/reviewer and not into git

<---------- goes into git ------------>
Created attachment 126937 [details] [review] [review]
[04] Protect debug-only variables behind  DBUS_ENABLE_VERBOSE_MODE

From: Thomas Zimmermann <tdz@users.sourceforge.net>

Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
Reviewed-by: Simon McVittie <smcv@debian.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
<---------- goes into git end ------------>
<---------- only for reviewer start ------------>
---

No changes, just re-attaching to put it into sequence
<---------- only for reviewer end ------------>

You want to have the second part really into git ?

(In reply to Philip Withnall from comment #6)
> (In reply to Ralf Habacker from comment #5)
> > for example git-bz attach does not allow to add additional
> > text in the created bug tracker comment
> 
> Write it as the commit message body.
> 
> > As freedesktop.org came up with phabricator they introducted Arcanist too,
> > the command line patch manager, which looked to me as a way to improve
> > things in this area especially for non-every-day-dbus-hacker.
> 
> git-phab is a whole lot nicer to use (for my workflow, at least) than arc.
> 
> https://phabricator.freedesktop.org/tag/git-phab/

This requires to have a file called .arcconfig into dbus git repo with the following content:

{
  "phabricator.uri" : "https://phabricator.freedesktop.org/",
  "projects" : "dbus"
}

Should I add this ?

(In reply to Philip Withnall from comment #6)

> git-phab is a whole lot nicer to use (for my workflow, at least) than arc.
> 
> https://phabricator.freedesktop.org/tag/git-phab/

I evaluated this tool: 

1. I installed it according to https://pypi.python.org/pypi/git-phab/1.9.0
2. git-phab does not work with python < 3.4 because it uses two methods newly introduced in 3.4 (re.fullmatch, subprocess.check_output parameter 'input').
3. I added .arcconfig mentioned in comment 8
4. I did run git-phab log and got 
850932a — Not attached — Fix double printing function name in _dbus_verbose() messages.
5. I want to attach patches to a bug and dir run git-phab attach --help to see how to use it. I got
usage: git-phab attach [-h] [--reviewers <username1,#project2,...>]
                       [--cc <username1,#project2,...>] [--message <message>]
                       [--task [<T123>]] [--remote <remote>] [--assume-yes]
                       [--projects <project1,project2,...>]
                       [<revision range>]
positional arguments:
  <revision range>      commit or revision range to attach. When not
                        specified, the tracking branch is used

optional arguments:
  -h, --help            show this help message and exit
  --reviewers <username1,#project2,...>, -r <username1,#project2,...>
                        A list of reviewers
  --cc <username1,#project2,...>, --subscribers <username1,#project2,...>
                        A list of subscribers
  --message <message>, -m <message>
                        When updating a revision, use the specified message
                        instead of prompting
  --task [<T123>], -t [<T123>]
                        Set the task this Differential refers to
  --remote <remote>     A remote repository to push to. Overrides
                        'phab.remote' configuration.
  --assume-yes, -y      Assume `yes` as answer to all prompts.
  --projects <project1,project2,...>, -p <project1,project2,...>
                        A list of `extra` projects (they will be added toany
                        project(s) configured in .arcconfig)

'--task ' indicates that it is required to use phabricator task system to manages reviews or did I missed something ?

(In reply to Ralf Habacker from comment #5)

here is a git-bz evaluation:

I have the following patch with which I want to open a new bug
850932a — Fix double printing function name in _dbus_verbose() messages.

1. I did run git-bz file dbus/core 850932a and got 

1.1 a new bug at https://bugs.freedesktop.org/show_bug.cgi?id=98089  (+)

1.2.the new bug contains an initial empty comment (-)

From the help of git-bz file 

Usage: git bz file [options] [[<product>]]/<component>] (<commit> | <revision range>)

Options:
  -h, --help            show this help message and exit
  -b <host or alias>, --bugzilla=<host or alias>
                        bug tracker to use
  -u, --add-url         rewrite commits to add the bug URL [default]
  -n, --no-add-url      don't rewrite commits to add the bug URL

it looks that there is no option to add an inital comment

1.3 the patch has been rewritten to include the bug number befor submitting (+)

1.4 the patch has been added to the bug (+)

Now I'm waiting for a review for further processing.

(In reply to Ralf Habacker from comment #10)
> 
> Now I'm waiting for a review for further processing.

1.5 I applied the changes required from the review and updated the patch.

1.6 I did run git-bz attach -e <commit-id>. 

1.7 I got an editor to add comments to the bug (+)
It is important to use the '-e' option otherwise the patch is directly attached and I'm not sure if the previous patch would be made obsolate too in this case. I need to check this later.

1.8 Additional in the editor I could see that a line starting with obsolates: <text> has been added probably to remove the previous patch (+)

1.9 I did not enter any additional comment and submitted the change. The result is that there is an additional comment with 
1.9.1 the previous patch be made obsolate (+)
1.9.2 the changed patch added  (+)
1.9.3 and a few lines added with the text 'Bug:' without any further text (-)

(In reply to Ralf Habacker from comment #11)

1.10 After patch has been fixed and reviewed it can be pushed into repo by running git-bz push

1.11 Assuming we are on master branch the commits above origin/master are now pushed to origin master (+)

1.12 Then an vi based editor is opened to finish the bug with a similar content (+)
----snip-------------------------------------------
# Bug 98089 - Fix double printing function name in _dbus_verbose() messages. - NEW
# https://bugs.freedesktop.org/show_bug.cgi?id=98089
# Enter comment on following lines; delete everything to abort

Attachment 127022 [details] pushed as 487a26f - Fix double printing function name in _dbus_verbose() messages.
# Comment to keep bug open
# possible resolutions: [F]IXED, [I]NVALID, [WON]TFIX, [WOR]KSFORME, [NOTA]BUG, [NOTO]URBUG
Resolution: FIXED

# To mark patches obsolete, uncomment below
obsolete @127022 - Fix double printing function name in _dbus_verbose() messages.
----snip------------------------------------------

1.13 The line starting with 'Attachment' has been automatically added by git-bz indicating that the commit has been pushed (+)
1.13.1 A minor issue is that there is no indication of the branch to push into.

1.14 The line starting with 'Resolution' has been added to automatically close the bug (+)

1.15 The line starting with 'obsolate' has also been added to automatically make the patch obsolate (+).

1.16 After submitting one comment has been added to the bug, the attachment has been made obsolate and the bug has been closed, (+)

Next evulation needs to check multiple patches and patchsets.

(In reply to Simon McVittie from comment #4)
> I want to spend my
> limited D-Bus time on fixing D-Bus, not on fighting with versions or
> configurations of Phabricator that aren't necessarily mature yet.

This comment was prescient.

phabricator.freedesktop.org is being retired in favour of gitlab.freedesktop.org. I’ve archived our project on Phab (https://phabricator.freedesktop.org/project/manage/67/), which was (as it turns out, thankfully) never used.

I think smcv’s comment still stands for whether we want to migrate to gitlab.freedesktop.org: it’s too early to tell whether that would be a good long-term.

GNOME is now locked into migrating to gitlab, so they’re going to rapidly get a lot of experience about how it changes/improves/breaks their workflows. If that’s all looking good after a year or so, and if gitlab.freedesktop.org is supported long-term, I’d be in favour of moving over then. A lot can change in a year, though.

(I think the main advantage I would look forward to in gitlab is continuous integration. It can do CI builds per merge request, so we essentially get try-server support on multiple platforms.)

I’ll keep this bug open for now.

(In reply to Philip Withnall from comment #13)
> (In reply to Simon McVittie from comment #4)
> > I want to spend my
> > limited D-Bus time on fixing D-Bus, not on fighting with versions or
> > configurations of Phabricator that aren't necessarily mature yet.
> 
> This comment was prescient.

Very.

> phabricator.freedesktop.org is being retired in favour of
> gitlab.freedesktop.org. I’ve archived our project on Phab
> (https://phabricator.freedesktop.org/project/manage/67/), which was (as it
> turns out, thankfully) never used.
> 
> I think smcv’s comment still stands for whether we want to migrate to
> gitlab.freedesktop.org: it’s too early to tell whether that would be a good
> long-term.

I'm much more optimistic about GitLab. For Phabricator, we were one of the first (apart from very early deployments by WikiMedia, KDE, Haskell, LLVM and Enlightenment) to push on to Phabricator, and probably the first 'forge'-type site - rather than a single focused project - to try it. The conclusion was that the UI just didn't work at all for loose collections of projects, and was also pretty hostile to drive-by contributors.

With GitLab, we have GNOME and Debian both piloting the way ahead of us - as well as, er, actual GitLab.com - so we're at least on far better-trod ground.

It certainly is happening in _some_ capacity: at some point, git.fd.o/anongit.fd.o/cgit.fd.o will all in fact be served by GitLab, so its use will be mandatory in that sense. None of the other services are planned for deprecation though: we would certainly encourage people to migrate workloads like review and issue tracking to GitLab where appropriate, but we have no plan/timeline for deprecation of tools like Bugzilla. If we did, that would be informed by discussion with all the affected projects beforehand ...

see https://bugs.freedesktop.org/show_bug.cgi?id=73636#c17 how to add reviewers to a series of patches.

Comment #4 still stands, as far as I'm concerned. When something other than Bugzilla is the "boring technology", we can use that. Perhaps that will be Gitlab issues and pull requests, or perhaps it will be something else. Until then, please keep fighting with Bugzilla.

(FWIW, I mostly just attach attachments through a web browser, rather than using git bz - yes it's a bit laborious, but writing and testing the patch and writing a good commit message takes much longer than attaching it, so it's hardly significant.)

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/136.