Last modified: 2014-04-22 20:22:51 UTC
Not sure whether it worked before upgrading. My name is not listed correctly in this line: <wikibugs> (NEW) {{[[a]]}} is not parsed correctly - https://bugzilla.wikimedia.org/42773 normal; Parsoid: General; ()
I don't see how that is a Bugzilla bug and not a wikibugs problem. :)
Dup of bug 18831 comment 17? In case this is an issue with Bugzilla code: I don't plan to fix it if it requires changing upstream code.
As far as I can tell, the name is missing for every new bug since the 4.2.4 upgrade.
(In reply to comment #3) > As far as I can tell, the name is missing for every new bug since the 4.2.4 > upgrade. You're right.
*** Bug 42852 has been marked as a duplicate of this bug. ***
From bug 42852 : The wikibugs perl script does not handle multi part mime message and ends up without any email body to parse. Additionally, the field name, we used to find out who did the action, has changed from ReportedBy: to Reporter:.
(In reply to comment #6) > The wikibugs perl script does not handle multi part mime message and ends up > without any email body to parse. I'm not sure this is accurate. I would think that if the bot were now receiving HTML e-mails, the parsing would've broken much more severely. And, in any case, wouldn't it simply be a matter of logging in to the wikibugs-l Bugzilla account and toggling its e-mail user preference? > Additionally, the field name, we used to find out who did the action, has > changed from ReportedBy: to Reporter:. This is probably the root cause of this bug. The bug summary has been recently updated to blame HTML e-mail, but I suspect the new bug summary is simply wrong.
My assumption comes from reading the wikibugs perl script and we indeed need to fix both issues. To rephrase it: The HTML mails comes with both a text and a HTML version which are encapsulated using MIME. The script does not support MIME and can not see the mail content. Once that has been fixed, a field name has been changed and will need to be changed too.
Switching the wikibugs-l@ account to plain text is easily possible, but I am not subscribed to wikibugs-l@lists.wikimedia.org so I have no idea who is interested and who isn't in keeping bugmail as plain text instead of HTML. On wikitech-l@ it sounded like a majority prefers HTML.
Wikibugs *is* receiving plaintext mails from wikibugs-l.
*** Bug 43119 has been marked as a duplicate of this bug. ***
gerrit change I0e785f34 by AzaToth (Carl Fürstenberg) should fix this.
Change is merged, but deployment is on hold. It has something to do with wikibugs not yet being fully git-compliant.
(In reply to comment #13) > Change is merged, but deployment is on hold. It has something to do with > wikibugs not yet being fully git-compliant. Afaik, it's two things, 1. Change I0dab6f52 was never merged, which commit 60dd706256cebe656790eac93b269621b958ed92 refers to 2. mchenry has a too old copy of git, unable to clone current git repos (must be really old then....)
(In reply to comment #13) > Change is merged, but deployment is on hold. It has something to do with > wikibugs not yet being fully git-compliant. Requires https://gerrit.wikimedia.org/r/#/c/44454/
What's the status on this? Which change in gerrit is the one that fixes this bug in wikibugs? The ones I see linked here have already been merged.
The overal status is that Wikibugs sucks by design. The culprits are: - use the perl language (we prefer php / python) - badly written code - lack of unit tests - lack of integration tests - runs directly on the mail server - require ops to do anything on it Petr Bena wrote another bot that consume RSS feed, that might be a slightly better design. That bot is running on a labs instance as far as I know. What we would need to do is startup a proper project with someone being in charge of listing the product requirement. Then write down some technical specifications and have a virtual team to start implementing them. Ideally Bugzilla would offer an easily parseable feeds of its events and some to be written python script would consume the feed on the Bugzilla server to generate the notifications. Overall I think wikibugs is considered very low priority given the amount of stuff we already have to implement / unbreak whatever. I am not volunteering :-)
(In reply to comment #17) > What we would need to do is startup a proper project with someone being in > charge of listing the product requirement. Then write down some technical > specifications and have a virtual team to start implementing them. > > Ideally Bugzilla would offer an easily parseable feeds of its events and some > to be written python script would consume the feed on the Bugzilla server to > generate the notifications. Related: bug 40970, and more specifically, bug 40970 comment 4.
wm-bot is written in c#, I don't really understand what you need, but wm-bot is already open source and already can be maintained by anyone who volunteers. Only problem I see is that bugzilla doesn't provide good machine parseable output of its events. Should there be any plugin for bugzilla that enables that, we should install it. Regarding - lack of unit tests - lack of integration tests I have no idea what you mean. If you need any other feed, it's no problem, wm-bot is very extendable - right now everything is implemented as plugins to a very lightweight and fast core
Peter > I was refering to the wikibugs perl script, not your wm-bot C# tool :-]
In reply to comment #16) > What's the status on this? Which change in gerrit is the one that fixes this > bug in wikibugs? The ones I see linked here have already been merged. Agreed, and thus changing bug status. For what it's worth, if I clone wikibugs on my local machine and run it on a NEW bug mail, it reports the reporter as "(tim)" in my case, while the deployed wikibugs says "()". So maybe I am doing something wrong (or right?), or the deployment process is faulty. Could some ops please verify: - what script is called according to the exim config on mchenry, and - what the MD5/SHA1/whatever of the script /as/ /deployed/ is?
Tim, this is already fixed. I described the possible root causes in Comment #6: - wikibugs not support MIME message: turns out to not be an issue since it receives plain text message - Reporter: field changed to ReportedBy: . That has been fixed by Carl in https://gerrit.wikimedia.org/r/#/c/44094/ So on your local machine you get a fixed up version. What needs to be done is to get the production version to be refreshed by ops and have make sure it is still working.
(In reply to comment #21) > [...] > Could some ops please verify: > - what script is called according to the exim config on mchenry, and > - what the MD5/SHA1/whatever of the script /as/ /deployed/ is? Any news on this or the bug in general? The symptoms still appear in #mediawiki: | [00:55:21] <wikibugs> (NEW) CirrusSearch: Can't reindex commons.... - https://bugzilla.wikimedia.org/60854 normal; MediaWiki extensions: CirrusSearch; ()
Tim Landscheidt wrote: > Any news on this or the bug in general? See Comment #17 (ie: need to redesign wikibugs to no more be a hook on the mail server)
(In reply to comment #24) > > Any news on this or the bug in general? > See Comment #17 (ie: need to redesign wikibugs to no more be a hook on the > mail > server) I assume it's a *lot* easier to have someone check/deploy a working version of wikibugs than to rewrite it from scratch :-).
