Page MenuHomePhabricator

Default Assigned To lists in Bugzilla must be set up for CC as Herald rules in Phabricator
Closed, ResolvedPublic

Description

From the description at T259: Bugzilla to Maniphest import script (tracking):

Default mailing list accounts such as wikibugs-l@lwo, wikidata-bugs@lwo, Pywikipedia-bugs@lwo should be set up in Phab (see T453!) and to watch projects via Herald (see https://secure.phabricator.com/book/phabricator/article/herald/ ) which they have been subscribed to before in Bugzilla (can be checked via https://bugzilla.wikimedia.org/editusers.cgi ).

Event Timeline

Qgil raised the priority of this task from to Needs Triage.
Qgil updated the task description. (Show Details)
Qgil added a project: Bugzilla-Migration.
Qgil changed Security from none to None.
Qgil subscribed.

CC'ing Mukunda as he's set up one mailing list already (IIRC).

Note that wikibugs-l@lwo is slightly special in Bugzilla as it is set up as "globalwatchers: users who should receive a copy of every notification mail the system sends." (obviously that excludes stuff that the user cannot access, such as Security tickets, but apart from that it receives all bugmail no matter if it's set as assignee somewhere or not).

  • wikibugs-l@lwo is BZ default assignee or default CC on
    • Everything except for access-restricted stuff
  • Pywikipedia-bugs@lwo is BZ default assignee or default CC on
    • Pywikibot-* (well, all components under Pywikibot product)
  • tools-nlwikibots@lwo is BZ default assignee or default CC on
    • Tool_Labs_tools-nlwikibots
  • wikidata-bugs@lwo is BZ default assignee or default CC on
    • MediaWiki_extensions-Ask
    • MediaWiki_extensions-DataTypes
    • MediaWiki_extensions-DataValues
    • MediaWiki_extensions-Diff
    • MediaWiki_extensions-ValueFormatters
    • MediaWiki_extensions-ValueParsers
    • MediaWiki_extensions-ValueValidators
    • MediaWiki_extensions-WikibaseDatabase
    • MediaWiki_extensions-WikibaseQuery
    • MediaWiki_extensions-WikibaseQueryEngine
    • MediaWiki_extensions-WikidataClient
    • MediaWiki_extensions-WikidataRepo
    • Wikimedia-Wikidata
    • Wikimedia_Labs-wikidata

There's just one problem. I need someone who is a mailing list admin to allow phabricator to send mail to the list...

In T496#6521, @mmodell wrote:

There's just one problem. I need someone who is a mailing list admin to allow phabricator to send mail to the list...

Bottom of https://lists.wikimedia.org/mailman/listinfo/wikibugs-l says that @chad could add it.

If that works, I can reach out to the other mailing lists admins.

(Curious if Mailman will strip in-reply-to with regard to https://secure.phabricator.com/book/phabricator/article/configuring_inbound_email/ )

In the meantime, wikibugs-l@lwo has been set up in T453.

If that works, I can reach out to the other mailing lists admins.

Do you want me to do that and ask the other mailing list maintainers to accept mail notifications from Phabricator?

Qgil triaged this task as Medium priority.Oct 8 2014, 10:07 PM

I have sent emails to the admins of the remaining three mailing lists configured in Wikimedia Bugzilla to please configure Mailman to allow mail notifications from Wikimedia Phabricator.

I am going to update this ticket once done so we can add those mailing lists here in the Phabricator configuration.

  • Done: Amir set up pywikipedia-bugs@ to accept notifications from Phabricator.
  • Done: JohnLewis set up wikidata-bugs@ to accept notifications from Phabricator.
  • Still waiting for reply from tools-nlwikibots@.

Update: Admins of all four mailing lists used in Bugzilla have set up their Mailman configurations to allow Phabricator send notification emails to those mailing lists now. So we can set those lists up now in Phab.

I have created those mailing lists in Phabricator, see https://phabricator.wikimedia.org/mailinglists/ so that part of the task is fixed.

I guess the next step for the stuff in T496#6078 is creating Herald rules?

@Aklapper do you need help to finish this task?

Looking at bugzilla_create.py in phabricator/tools.git,

mlists = bzdata_yaml['assigned_to_lists'].split(' ')
vlog("Mailinglists: " + str(mlists))
assignee = buginfo['assigned_to']
if assignee in mlists:
    ccphids.append(mailinglist_phid(assignee))

so I think code-wise we are fine (or I need more coffee this morning) but we haven't tested this yet by actually setting up mailing lists under https://bugzillapreview.wmflabs.org/mailinglists/ and that's why we see "bzimport added a subscriber: Unknown Object (????)" items in the preview instance, as reported in T698.

Do we consider this sufficient proof that things work?

So this logic will assign / cc lists but will not create them to begin with
if absent

In T496#17969, @chasemp wrote:

So this logic will assign / cc lists but will not create them to begin with if absent

...and as all four mailing lists have been created in this production instance already, we are fine?

So I was looking at the migration code.
As we hadn't set up any mailing lists in the Bugzilla preview instance before importing Bugzilla tickets I didn't realize that the import script will also restore these mailing lists as task assignees in Phab.

Bugzilla uses the wikibugs-l@ mailing list as (default) assignee for many components because Bugzilla does not allow having no assignee set for a task.
Having non-human assignees in Phab on 48000 out of our 73000 Bugzilla tickets feels "suboptimal" as having no assignee set communicates way clearer that nobody is working on a task.

Wondering whether to handle this special case: If assignee is "wikibugs-l@" (44500 tickets, 11200 of them open) and the ticket is in an open status, keep the assignee field empty.

Guess I should also talk to Pywikibot (800 tickets, 440 of them open) and Wikidata (2850 tickets, 650 of them open), but we could also mass-remove their mailing list default assignees from open tickets in Phab after having migrated from Bugzilla as those numbers are way smaller.

Yeah, if we (cough, rather you) could make the script check whether the assignee is wikibugs-l@lwo and at least for open tickets remove that assignee and leave the Assignee field empty instead: That would be pretty awesome.

No idea if we can check the ticket status at that stage and if that's better or worse performance-wise...

We have these four mailing lists defined in https://git.wikimedia.org/blob/phabricator%2Ftools.git/4d573d99b5e7151be357c85d624ffcc0268b5e3a/data%2Fbugzilla.yaml and Chase said that we can simply NOT assign tasks to these accounts (rough summary).

Sorry if this sounds excessively bureaucratic, but can you please create a task specific for this problem under Bugzilla-Preview and blocking T259? It is something that the migration script needs to handle and considering that it affects 1000s of bugs, we better test it in the preview.

I've had a look at the test instance and I was wondering what how are we going to migrate other default assigned-to/cc?

I am receving notification for example all bugs related to the Collection extension, but https://bugzillapreview.wmflabs.org/tag/mediawiki-extensions-collection/ project has no members/watchers.

https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla#Bugzilla_data_migrated currently says:
"If you are on the "default CC" list of some Bugzilla components you will need to "watch" or join the corresponding project in Phabricator again in order to automatically receive notifications (for newly reported tasks only)."

In T496#17969, @chasemp wrote:

So this logic will assign / cc lists but will not create them to begin with
if absent

FWIW no longer true. assigning tickets to lists by default was determined as bad behavior.

Is this task resolved, then? I mean, does this mean that the script will not assign these tasks to anybody in Phabricator?

should probably be confirmed with the list owners of wikibugs-l . they have received every BZ update in the past. do they really expect the list to close?

https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Wikibugs-l list run by brion at wikimedia.org, innocentkiller at gmail.com, wikipedia.danny.b at email.cz , heh :)

wikibugs-l, as it existed, was meant to be a firehose of all bug activity (sans CC changes & security things). Since we're using Phabricator for things other than just bugs, it means that "cc it to everything" approach doesn't work anymore (see T763: Phabricator far too spammy and off-topic to continue posting to wikibugs-l).

I honestly don't care though :) I've never subscribed to wikibugs-l, and I don't even remember when/why I was added as list admin. I think it'd be far more useful to get the input of someone who is subscribed. I doubt they anticipated the list to close with the move to Phabricator.

sounds like it would be nice to announce the plan on that list itself

The idea is that wikibugs-l will continue to receive more or less the same type of bugmail that has been receiving with Bugzilla. This task and T763: Phabricator far too spammy and off-topic to continue posting to wikibugs-l try to deal with the problem of not sending too little nor too much.

In T496#21320, @Qgil wrote:

The idea is that wikibugs-l will continue to receive more or less the same type of bugmail that has been receiving

that will need actions by the list admins, to allow mail from a new address / sender filters to make the list accept mail from phabricator

In T496#21321, @Dzahn wrote:
In T496#21320, @Qgil wrote:

The idea is that wikibugs-l will continue to receive more or less the same type of bugmail that has been receiving

that will need actions by the list admins, to allow mail from a new address / sender filters to make the list accept mail from phabricator

That's been done. Did I misread somehow that we're not going to be sending anymore?

T763 is basically about wikibugs-l users complaining about Phabricator spam, so I guess the list does accept mail from phabricator. :)

In T496#21336, @Chad wrote:

That's been done. Did I misread somehow that we're not going to be sending anymore?

maybe. further above it says "FWIW no longer true. assigning tickets to lists by default was determined as bad behavior."

This task is about the migration, and the goal is to solve the fact that there are 1000s of bugs assigned to wikibugs-l and other mailing lists, while in Phabricator they should be simply assigned to none.

T763 is about maintaining a Herald rule to CC the wikibugs-l mailing list in the projects that are relevant about wikibugs-l, and not the rest. What is being sent to wikibugs-l is defined by this Herald rule. Please go to T763 if you want to discuss what should or should not be sent to wikibugs-l.

In T496#21307, @Dzahn wrote:

should probably be confirmed with the list owners of wikibugs-l . they have received every BZ update in the past. do they really expect the list to close?

That's a different topic. This task is about default assignees of tasks not about triggering mail notifications. wikibugs-l is a "globalwatcher" entry in Bugzilla so whether it's set as assignee or not does not influence mail notifications.

In T496#21321, @Dzahn wrote:

that will need actions by the list admins, to allow mail from a new address

Done already, see T496#8531 above.

Discussion about CCing wikibugs-l is T763.

In T496#21306, @Qgil wrote:

Is this task resolved, then? I mean, does this mean that the script will not assign these tasks to anybody in Phabricator?

yes and seems done to me?

I stll need to check if all Herald rules are in place to send update mail to the lists defined in https://phabricator.wikimedia.org/mailinglists/ for the projects defined in T496#6078 and need to double-check https://phabricator.wikimedia.org/herald/rule/5/

Aklapper renamed this task from Default Assigned To lists in Bugzilla must be set up in Phabricator to Default Assigned To lists in Bugzilla must be set up for CC as Herald rules in Phabricator.Nov 12 2014, 5:44 PM
Aklapper raised the priority of this task from Medium to High.Nov 17 2014, 1:01 PM

<andre__> chicken and egg problem with setting up the default CC mailing lists for wikidata and pywikibot, because the condition is based on projects in Phab that do not exist yet
so either I set these up right after importing
or I already create these projects before importing, but no idea if the import script barks if it tries to create projects like "MediaWiki-extensions-WikibaseQuery" product and such projects already exists in Phab
<chasemp> it should not bark

I've set up corresponding projects (see last comment as we're a few hours before starting migration).

I have created the Herald rules 6 to 8 which cover Pywikipedia-bugs@lwo, tools-nlwikibots@lwo and wikidata-bugs@lwo according to what these lists were also CCed on by default in Bugzilla. Those lists now receive CC notifications for corresponding tasks in their fields.
I've set the conditions to "When all conditions met: Projects include any of $Projectnames AND Projects do not include $Security* project".
(Mukunda said I don't need to set the ensure security policy action explicitly because that is running in it's own global rule anyway.)

Remaining wikibugs-l@lwo to get covered by Mukunda in T763 (and cf T453) as discussed in meeting on 20141119.

Not sure whether to leave this ticket open for wikibugs-l@lwo or if T763 sufficiently covers that already.

T763 is still open for wikibugs-l. Here we can resolve the task for the rest of the lists. Have you tested whether the rule works? When the tests are ok, this task can be closed.

https://phabricator.wikimedia.org/T1391 did not successfully deliver the email, not shown here.

I guess because of https://gerrit.wikimedia.org/r/#/c/169290/ which was done on Oct 28 while I contacted mailing list admins in the middle of Oct.

I have contacted them again asking to adjust that address.

We still need to test this task... (testing comments over email, sorry)

Works for Wikidata (see T75689).
Does not work yet for Pywikibot (see T75688). Sent an email to ml admins.
Also compared the Herald rules again to make sure it's not a fault of our Phab config.

Pywikibot in T75688 and Wikidata in T75689 work now as expected.

I've also chatted with Valhalla about tools-nlwikibots@ that I have not tested / will not test that one, so he is aware.

wikibugs-l@ is not working and still discussed in T763.

Closing this ticket; let's please continue with what we want to do with wikibugs-l@ in T763.

Thanks!