Bugzilla Spam

[schveiguy]

Not sure if this is dlang-bot or not, but I'm sure you guys also have some insight on this.

I'm seeing a lot of spam on bugzilla when git merging happens. e.g.: https://issues.dlang.org/show_bug.cgi?id=9287#c7

Is there a way to restrict the commit actions to trigger a comment on bugzilla to

1. Only stable or master branch commits
2. The first time a commit happens (i.e. if you merge from stable to master or vice-versa, the commit is ignored)

Not well-versed enough in how this works to have any idea what to do. Just thought I'd post an issue.

[wilzbach]

Not sure if this is dlang-bot or not, but I'm sure you guys also have some insight on this.

This isn't the bots doing. That's the GitHub-Bugzilla bridge. We could replace this entirely with the bot and prevent the spam, but this more or less depends on @braddr making the Bugzilla REST API publicly available (Bugzilla comes with a REST API).

Just thought I'd post an issue.

Yep I totally agree that it's annoying.

[MartinNowak]

I've updated {dmd,druntime,phobos,installer,tools,dlang.org} to only trigger on master commits.
That's where everything ends up, and it's the least confusing to only close bugs when all branches have the fix.
That's about all you can configure there, but it might have exactly the effect you want.

[schveiguy]

thanks! That works for me. May want to post something about it so people aren't confused when their stable branch fixes don't close the bugs.

[MartinNowak]

thanks! That works for me. May want to post something about it so people aren't confused when their stable branch fixes don't close the bugs.

Yes @schveiguy, good idea to inform people, but please don't ask me to do stuff you can do yourself ;).

[MartinNowak]

That unfortunately collides a bit with our changed tool when generating changelogs solely based on stable commits. So now building a release would require to merge back stable beforehand for the bug to be closed :/. Somewhat problematic while that still isn't automated.

[schveiguy]

But a merge back to master from stable is probably a great idea before a release -- it would be odd for a bug fixed in a stable release not to be in master when the release is made.

[MartinNowak]

Atm. I do it as part of the release script [¹].
If building the changelog depended on sth. being merged, then my release process suddenly is spreaded over several hours instead of taking 20 minutes, that's unacceptable.
Already the delayed automated website update (easily 1hr.) is PITA to work with.
I'm sure that we can automate merging back stable, so that things should be clear.

For the time being we might want to change the FIXED&RESOLVED criteria to commit in stable matches fix Issue 12345 & not REOPENED or so to workaround this problem.
It's bad for processes to unnecessarily create dependencies.

But a merge back to master from stable is probably a great idea before a release -- it would be odd for a bug fixed in a stable release not to be in master when the release is made.

What's odd about that? Master is always in development and it's not user-faced.
But sure we want to minimize the time for merging back to avoid unnecessary confusion.
If you have any good idea for automating merging back of stable, leave them at #165.