We already have some scripting in place that sends a comment to a bug if the fix gets integrated. It would be nice to also notify the bug about a patch being uploaded to gerrit, so people can test the fix. https://github.com/openstack-ci/gerritbot I likely a good base for that.
Could you point me to the code for the current git => bugzilla bridge implementation? Do we want to update bz entry on every comment/pacthset sumbission (lie openstack guys on launchpad) or only after patchset was merged?
Found the python script that does the job on openstack site: https://github.com/openstack/openstack-ci-puppet/blob/master/modules/gerrit/files/scripts/update_bug.py and here is the place where this script is called: https://github.com/openstack/openstack-ci-puppet/blob/master/modules/openstack_project/files/gerrit/patchset-created
Discussion on IRC with mogi: <moggi> _david_: IMHO we should not pollute bug reports with changes to a patch, we already only announce bug fixes in master and in release branches and not in feature branches to reduce the amount of bugzilla spam <moggi> _david_: I'm not sure but I thinkw e don't need to change anything for gerrit at the bugzilla integration, it should work out of the box as soon as gerrit is the owner of the git repos <_david_> moggi: While i understand your opinion the other guys (Openstack) announce it on their bug tracking site: launchpad <moggi> _david_: if you decide to also announce please use another user to report comments, I think some developers want to block this user from sending mails <moggi> _david_: I personally don't want these bugzilla comments and if they are added please use a new bugzilla user for them so that it is possible to prevent this spam so we shouldn't possibly change anything
Please remember that some of us are put into cc for some hundred bugs by the qa team. We already get quite a lot of bugzilla mail, if there are now even more mails that are totally useless for us we will miss important bugzilla mails. Some more information about the git bugzilla script. The intention of it was mainly to report to the reporter and the QA guys when a fix will be included into a release branch and help them test the fix without checking back which builg will contain the fix. A developer who would be the target audience for comment notification in gerrit has other ways to get this information than to use bugzilla.
Indeed bugzilla should not be spammed with every comment on gerrit, but it should get post a 'newchange' notification (which means that a patch, that is: real code) has been uploaded. This way people interested in the bug (who are good candidates for review and testing) will get a hint without duplicating the review on bugzilla.
Regardless of the potential usefulness for specific types of notifications for LibreOffice development: In Mediawiki we use https://gerrit.googlesource.com/plugins/hooks-bugzilla/ for this task, see https://bugzilla.wikimedia.org/show_bug.cgi?id=17322
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility. see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Wireshark project (https://wireshark.org/) has also moved to Gerrit+Bugzilla and would be interested in whatever comes of this integration.
(In reply to comment #8) > Wireshark project (https://wireshark.org/) has also moved to Gerrit+Bugzilla > and would be interested in whatever comes of this integration. Every one out there is using this combination. It's about minutes to set up the all around integration. Unfortunately some core developer vetoed this integration. So there is not integration for now. But if would want to, it's just a matter of installing ITS-Bugzilla plugin, set it up and you are done [1]. [1] https://gerrit-review.googlesource.com/#/admin/projects/plugins/its-bugzilla
(In reply to comment #4) > Please remember that some of us are put into cc for some hundred bugs by the > qa team. (...) if there are now even more mails that are totally useless > for us we will miss important bugzilla mails. > A developer who would be the target audience for comment notification in > gerrit has other ways to get this information than to use bugzilla. IMHO a single notification of "a patch for this bug has been submitted to branch X" (so one comment per gerrit change and per release (not feature) branch) would be relevant to the CCed developers. Else, they get exactly zero notification about it, unless the patch uploader specifically adds these developers as reviewers on the gerrit side. Actually, I kinda would appreciate an optional "automatically make me a reviewer on each gerrit change that is related to a bug where I'm CC" feature. > Some more information about the git bugzilla script. The intention of it was > mainly to report to the reporter and the QA guys when a fix will be included > into a release branch and help them test the fix without checking back which > build will contain the fix. For the QA guys, which I presume can be expected to know about our procedures, then we don't even need a comment, the whiteboard keyword is enough. For the reporter, OK, he might not understand "target:x.y.z", the comment is more user-friendly.
EasyHack moved to https://redmine.documentfoundation.org/issues/1509
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyBeginner SkillScript TopicQA SkillInfra) [NinjaEdit]
Remove LibreOffice Dev List from CC on EasyHacks (curtailing excessive email to list) [NinjaEdit]