I'd rather say that in theory there could be a bot that

• adds a "patch-in-gerrit" keyword when a patch is submitted to Gerrit that mentions the bug number, plus adds a comment with the Gerrit ID in the bug report, and
• closes the bug report as RESOLVED FIXED once the patch is merged in Gerrit.

I haven't investigated if something like this exists already ( https://wiki.mozilla.org/Bugzilla:Addons would be a good starting point).
From a past life I remember vaguely that KDE Bugzilla uses some hooks for similar needs ("fixed-in" or so), and that Nokia used a bot internally between their code repository and their Bugzilla to achieve automatic resolving of tickets.

When an attachment is a patch there rather could be a comment that patches should preferably go to Gerrit directly, and link to http://www.mediawiki.org/wiki/Developer_access for instructions. However experience shows that many people don't see the "patch" checkbox anyway (which is likely why somebody introduced the "patch" keyword in this bugtracker, plus Bugzilla's non-trivial "custom search" query to find patches via this checkbox).

You're probably right about "patch-in-gerrit". This integration is part of bug 17322, though, and the there-mentioned use of it at Fedora is still alive and kicking today (haven't seen a KDE bug of mine resolved in a long time, so can't make statements about it :-)).

If "[x] patch" isn't common usage, one could also test for file names ending in ".patch" or ".diff". My assumption would be though that programmers who can fix MediaWiki code and know how to generate a patch will probably be smart enough to click it :-).

I do think that any mentioning of submitting to Gerrit should only occur after the patch has been safely added to Bugzilla's database so no code is lost.

Automatic closure as RESO FIXED submitting a patch won't work in each case.

[ The buggy ones ]

ie the cases we could ignore if Bugzilla users accept to be more disciplined

In Wikimedia product, Site config or extension setup components, when the operations change is merged, it's only a configuration file which have been edited. The real resolution is when we deploy the new files and so it becomes the production config.

Furthemore, imagine a scenario when an extension change requires also a core change. In the perfect world, we should open a new bug for the core change blocking the extension change. Don't automatically close allows not to be too pedantic with Bugzilla use and work pragmatically. This is bad, but this is how we sometimes worked in the past.

I remember also a wiki with 3 requests in a single bug, two fixed by changes pushed to Gerrit, one by intervention on the local wiki. We wanted to have the 3 resolved to close the bug. This is clearly a case where we should have created 3 new bugs, but we didn't.

[ The tricky ones ]
       ie the cases automatic closure will never work

Now imagine also we try something to fix a very complicated bug, like bug 37225 (an history corruption issue).

It required 6 changed merged to resolve the bug:
https://gerrit.wikimedia.org/r/#/q/project:mediawiki/core+topic:bug/37225,n,z

+ more changes to avoid similar situations in the future without an explicit reference to the bug (see the last comments)

I know this is the wrong bug, but I don't want to appear impolite.

(In reply to comment #3)

Automatic closure as RESO FIXED submitting a patch won't work in each case.

[ The buggy ones ]

ie the cases we could ignore if Bugzilla users accept to be more

disciplined

In Wikimedia product, Site config or extension setup components, when the
operations change is merged, it's only a configuration file which have been
edited. The real resolution is when we deploy the new files and so it becomes
the production config.

Furthemore, imagine a scenario when an extension change requires also a core
change. In the perfect world, we should open a new bug for the core change
blocking the extension change. Don't automatically close allows not to be too
pedantic with Bugzilla use and work pragmatically. This is bad, but this is how
we sometimes worked in the past.

I remember also a wiki with 3 requests in a single bug, two fixed by changes
pushed to Gerrit, one by intervention on the local wiki. We wanted to have the
3 resolved to close the bug. This is clearly a case where we should have
created 3 new bugs, but we didn't.

[ The tricky ones ]
       ie the cases automatic closure will never work

Now imagine also we try something to fix a very complicated bug, like bug 37225
(an history corruption issue).

It required 6 changed merged to resolve the bug:
https://gerrit.wikimedia.org/r/#/q/project:mediawiki/core+topic:bug/37225,n,z

+ more changes to avoid similar situations in the future without an explicit
reference to the bug (see the last comments)

The reality is that bugs were and are closed as RESOLVED FIXED when the patch is merged. Bug 17322 tries to automate just that; it doesn't force a committer to use a phrase that will trigger the auto-close when his patch doesn't fix everything, and it doesn't forbid a bug manager to close (or re-open) a bug manually if all conditions are fulfilled. If on deployment, not all bugs don't get the comment "Deployed.", that's also okay.

What's the point you are trying to make? It won't work in 100 % of all cases, so let's not even implement it for the 95 % where it saves time? Yesterday, there were 8548 open bug reports in MediaWiki. Should we take Wikipedia offline until they are all fixed?

The point I'm trying to make is I would prefer developers closes themselves bug with relevant comments if needed or allow the discussion about the bug to go on when needed.

I would also like to stress two of the newly appointed bug wrangler objectives:

(1) Grow a community of volunteer bug responders who help transfer issue reports from other communication channels to the bug tracker, and who share bug management responsibilities

(2) Clean up and organize the existing bug tracker backlog, identifying duplicated and outdated bugs

This translates a willingness to assign such bug closure responsibility to humans, instead to automated systems.

Now we can help to automatically close bug, adding a feature in Gerrit offering to close the bug at merge time, as you offered for patches.

"Yesterday, there were 8 548 open bug reports in MediaWiki. Should we take Wikipedia offline until they are all fixed?" doesn't constitute a logical argument, as:
(1) the number of open bugs is quantitative, the way we close bug is qualitative;
(2) the 8 548 bugs are in the immense majority bug not yet resolved or analyzed, not bugs resolved with forgotten closure;
(3) there is no need to close Wikipedia to fix bugs (we use continuous integration processes) (and by the way, not all open bugs are related to components used on Wikimedia projects);
(4) you start with the hypothesis 8 548 open bugs is bad and this amount should be decreased, I beg to differ, this proves we've a living bug report ecosystem, with users finding bugs and asking new features.

Why do you use such catastrophic exaggeration in a constructive dialog to find the better way to improve bugs handling?

(In reply to comment #5)

The point I'm trying to make is I would prefer developers closes themselves bug
with relevant comments if needed or allow the discussion about the bug to go on
when needed.

And that's something I disagree absolutely with. If some developer wants to manually close a bug or comment on it, he can do so. But why burden volunteer or paid developers with unnecessary, mechanical management tasks? There is a huge cost involved, but what is the benefit (besides your personal preference)?

I would also like to stress two of the newly appointed bug wrangler objectives:

(1) Grow a community of volunteer bug responders who help transfer issue
reports from other communication channels to the bug tracker, and who share bug
management responsibilities

(2) Clean up and organize the existing bug tracker backlog, identifying
duplicated and outdated bugs

This translates a willingness to assign such bug closure responsibility to
humans, instead to automated systems.

I don't see any such requirement. These tasks refer to bug triage that requires human assessment, not to have someone waiting for someone else's message "Bug fixed" to click on the button "Bug fixed".

[...]
"Yesterday, there were 8 548 open bug reports in MediaWiki. Should we take
Wikipedia offline until they are all fixed?" doesn't constitute a logical
argument, as:
(1) the number of open bugs is quantitative, the way we close bug is
qualitative;
(2) the 8 548 bugs are in the immense majority bug not yet resolved or
analyzed, not bugs resolved with forgotten closure;
(3) there is no need to close Wikipedia to fix bugs (we use continuous
integration processes) (and by the way, not all open bugs are related to
components used on Wikimedia projects);
(4) you start with the hypothesis 8 548 open bugs is bad and this amount should
be decreased, I beg to differ, this proves we've a living bug report ecosystem,
with users finding bugs and asking new features.

Why do you use such catastrophic exaggeration in a constructive dialog to find
the better way to improve bugs handling?

If all of this is true, why don't you want to apply the same continuous improvement process that we use on MediaWiki to its bug management and implement an initial auto-close on the commit of bug fixes even if there are cases where that will not be useful?

(In reply to comment #6)

(In reply to comment #5)

The point I'm trying to make is I would prefer developers closes themselves bug
with relevant comments if needed or allow the discussion about the bug to go on
when needed.

And that's something I disagree absolutely with. If some developer wants to
manually close a bug or comment on it, he can do so. But why burden volunteer
or paid developers with unnecessary, mechanical management tasks? There is a
huge cost involved, but what is the benefit (besides your personal preference)?

The benefit seems to me the increase quality of the bug resolution workflow.

Note I offered an hybrid solution. We could add a checkbox in Gerrit merge form (with a setting to have it checked by default) to close the linked bug in Bugzilla.

I would also like to stress two of the newly appointed bug wrangler objectives:

(1) Grow a community of volunteer bug responders who help transfer issue
reports from other communication channels to the bug tracker, and who share bug
management responsibilities

(2) Clean up and organize the existing bug tracker backlog, identifying
duplicated and outdated bugs

This translates a willingness to assign such bug closure responsibility to
humans, instead to automated systems.

I don't see any such requirement. These tasks refer to bug triage that
requires human assessment, not to have someone waiting for someone else's
message "Bug fixed" to click on the button "Bug fixed".

[...]
"Yesterday, there were 8 548 open bug reports in MediaWiki. Should we take
Wikipedia offline until they are all fixed?" doesn't constitute a logical
argument, as:
(1) the number of open bugs is quantitative, the way we close bug is
qualitative;
(2) the 8 548 bugs are in the immense majority bug not yet resolved or
analyzed, not bugs resolved with forgotten closure;
(3) there is no need to close Wikipedia to fix bugs (we use continuous
integration processes) (and by the way, not all open bugs are related to
components used on Wikimedia projects);
(4) you start with the hypothesis 8 548 open bugs is bad and this amount should
be decreased, I beg to differ, this proves we've a living bug report ecosystem,
with users finding bugs and asking new features.

Why do you use such catastrophic exaggeration in a constructive dialog to find
the better way to improve bugs handling?

If all of this is true, why don't you want to apply the same continuous
improvement process that we use on MediaWiki to its bug management and
implement an initial auto-close on the commit of bug fixes even if there are
cases where that will not be useful?

Because I disagree with your number of 95% and even if the approximate is right, I would prefer a 99.5% of useful score. 5% of errors isn't acceptable, there is an huge risk issues not totally resolved are forgotten.

Especially if we could offer a very easy way instead to close the bug merging the change.

(In reply to comment #5)

I would also like to stress two of the newly appointed bug wrangler objectives:
[...]
This translates a willingness to assign such bug closure responsibility to
humans, instead to automated systems.

I don't see that. You refer to bug fixing (RESOLVED FIXED), while the objectives refer to forwarding tickets into Bugzilla, and triaging older tickets (and if they cannot be reproduced close them as WORKSFORME when a specific commit fixing the issue cannot be identified).

A bug status like "Patch committed (available in Gerrit)" is basically covered in bug 39402 which depends on aforementioned bug 17322 (Gerrit/Bugzilla integration) which is currently being worked on, so I'm closing this as a duplicate.

• This bug has been marked as a duplicate of bug 39402 ***

(PS: As the bug summaries differ a bit at first sight: I'd like to get rid of all that patch keyword stuff in the long run, or at least have it automated.)