derp this is done.

Yeah, that directly helps with this. I think I have a pretty good plan for the actual mail part that isn't too crazy complicated, but the cutover/migration bit will be much simpler/smoother if we get things swapped over -- at least, most of the way -- ahead of this.

Just to clarify, it is good to be moving all the apps to modular transactions? This task is my primary motivator to cleaning that up.

I have a rough cut of this one.

One spanner in the works here is that not all applications with mail preferences are on Modular Transactions yet. I think these are missing:

Thanks, closing this one!

You should have sweeping janitorial powers as a member of Community now.

Or I guess, you* can close this since I can't. Whoops.

Scratch that, you're right @epriestley . We just got confused during the workflow and didn't realize jmeador previously accepted.

Whoops, I think I may have totally fudged the screenshots. Let me try to reproduce with proper screenshots.

It looks like before step (2), jmeador can only accept for one reviewer (the package), since he's already accepted for himself. The current rule is:

I may still do a bit of a UI touchup pass here but this can follow up in T10967, since there's still some other work to be done there (like purging the old double writes).

Just tested, works great. Thanks for the quick fix!

I think things should work now, let me know if you're still seeing issues. Thanks for the report!

Argh! I broke it while doing last-minute fixes to improve rendering, fix in a moment.

No prob! If it helps:

Thanks, that definitely looks like a bug.

Not sure if this is a known bug / missing feature, but FYI just in case...

I'm going to call this resolved; T9979 is the survivor for Files and the Maniphest case is probably more involved (T6721).

Ah. I think you'd just see this, then:

FWIW, All packages in our monorepo have weak dominion.

Overall, you only get checkboxes for users, packages and projects which are already reviewers, with the exception that you'll get one for yourself if you aren't a reviewer yet.

How do we envision these rules applying to the following situation?

Calling this resolved since the page is now tolerably bad (~5s) which more or less pulls this out of the realm of critical scaling issues.

@jmeador, I believe this is now resolved at HEAD. Let us know if you're still seeing issues after upgrading?

After implementing PHP7 support for XHProf and updating Lipsum, I used bin/lipsum to generate 4,000 packages owning 150,000 paths. I think I have an approximately-reasonable reproduction case locally now, which generates this profile (6.5s for a change affecting about 100 files):

As far as "opt-in", are you mostly concerned about performance?

As far as "opt-in", are you mostly concerned about performance?

NOTE: Since packages do not own paths exclusively, any user can create a package on / of every repository and be allowed to force-accept every package review because their "everything" package is now a containing package for all other packages. However, they could already just remove the reviewers, so I don't think this is important. We could add options to Owners (e.g., an optional whitelist of "Stronger" packages) or something to prevent this, but I don't plan to do this. Just fire anyone abusing it.

They are not related. That search uses fulltext indexes (see T11922 / T11741 for recent discussion), not ngram indexes.

I don't think this is quite the same issue, but seems related, so I thought I'd err on the side of not creating a dupe.

I'm just going to presume this is resolved, in some sense, by D17181, because you can now remove auditors regardless of other outcomes.

From elsewhere:

Partly, just haven't gotten there yet.

Looking through the code, looks like Maniphest doesn't use ngrams yet? Any reason?

Yes, you are correct, I want to wildcard the repository names. Thanks for your alternative fixes. The low priority is not a problem.

@pingpongboss, in T11787 it looks like you actually want to wildcard the repository names, not the paths?