I think we discussed somewhere already that complete migration of Bugzilla users was not a goal. Many of those "users" consist in a single and deprecated email address that not even the former owner can access to. "we have no way to know and contact previous subscribers and they have no way to recover lost subscriptions" was a reality well before Phabricator was in the horizon.

@Nemo_bis please provide a rationale for reopening it otherwise I'll re close it tomorroe.

As explained by Quim already here and in T896#939523, people not accessing (or not being able to access) their email accounts is not related to the migration from Bugzilla to Phabricator. That fact is just more visible since the migration.

@Nemo_bis: You did not reply to T95266#1185061, T95266#1185310, T95266#1218248 and I see no signs of "dismissing" here, just edit-warring...

Kind of wondering if there are also some misconceptions involved:

Claiming accounts in Phab (and previous activity imported from BZ) is not related to BZ being available/online.
BZ is not accessed from Phabricator during the account claiming process. Claiming contributions from Bugzilla depends on a separate database, unrelated to whether Bugzilla itself is online or offline.

In T95266#1242451, @Aklapper wrote:

Kind of wondering if there are also some misconceptions involved:

Claiming accounts in Phab (and previous activity imported from BZ) is not related to BZ being available/online.
BZ is not accessed from Phabricator during the account claiming process. Claiming contributions from Bugzilla depends on a separate database, unrelated to whether Bugzilla itself is online or offline.

Thanks for explaining. This is good to know and it alleviates the concern I saw here. @Nemo_bis: is this explanation sufficient?

As explained in T95266#1242451, T95266 does not block T95184 at all, hence I removed the Blocks/BlockedBy relation.

is this explanation sufficient?

No.

Claiming accounts in Phab (and previous activity imported from BZ) is not related to BZ being available/online.

It is, because if bugzilla is offline I can't contact users manually where phabricator fails to notify them.

It is, because if bugzilla is offline I can't contact users manually where phabricator fails to notify them.

So this seems like a more social issue than a technical one. Also the database dump will be available for a while before bugzilla is removed, won't that solve the issue as opposed to keeping bugzilla online for ever, letting it become exploitable and then all private data being leaked if a serious security issue is found in Bugzilla?

I don't know how simple and feasible this task would be but...

1. Extract all email addresses from old-bugzilla.
2. Extract all email addresses from Wikimedia Phabricator.
3. Remove the email addresses in both lists in order to get those that have no related Phabricator account.
4. Create a one-time mailing list in Mailman and mass-subscribe all the email addresses there.
5. Send a one and only email to that list, notifying about old-bugzilla being archived for good, and these email addresses (visible until now) being removed for privacy reasons, inviting them to join Phabricator to claim their tasks, etc.

As said above, I expect a majority of these email addresses to be obsolete today. Among the technically valid email addresses, if someone doesn't see or doesn't care about this last call, they probably won't care about joining Wikimedia Phabricator right now.

In T95266#1275491, @Qgil wrote:

I don't know how simple and feasible this task would be but...

1. Extract all email addresses from old-bugzilla.

On the bugs DB: SELECT login_name FROM profiles WHERE disable_mail != 1 AND disabledtext = "";

2. Extract all email addresses from Wikimedia Phabricator.

On the phabricator_user DB: SELECT address from user_email; (just for the records, there are also isPrimary and isVerified columns)

3. Remove the email addresses which are in both lists in order to get those that have no related Phabricator account.

Pseudo-query as this is probably cross-server, but could always import results of above queries into a local DB:
SELECT login_name FROM bugs.profiles WHERE login_name NOT IN (SELECT address from phabricator_user.user_email)

4. Create a one-time mailing list in Mailman and mass-subscribe all the email addresses there.

I'm missing Mailman skills to tell if I could a) mass-subscribe a given list of email addresses without b) triggering confirmation emails or such.

4. Create a one-time mailing list in Mailman and mass-subscribe all the email addresses there.

I'm missing Mailman skills to tell if I could a) mass-subscribe a given list of email addresses without b) triggering confirmation emails or such.

You can to both however I feel a throw away list is not really useful and I would not create such a list myself.

I'm proposing the Mailman list just to avoid the ugly method of BCCing hundreds of email addresses in batch emails. Anything sending those emails in a way that won't be caught by spam folders (at least not by design) would be good.

Anything sending those emails in a way that won't be caught by spam folders (at least not by design) would be good.

A script sending custom/context-sensitive messages one at a time, from a wikimedia.org email address, would be an alternative; we (well, Manuel) did such things in the past e.g. for events mailings.

It could pick the latest report filed (or touched) by the user and mention it as reason to login/register on phabricator. The Reply-To would ideally point to an appropriate OTRS queue.

Of course invites/notifications are just a first step, but one must start somewhere.