Is this possibly related to T1275?

I'm seeing the same thing:

D14846 should fix the package case, but I'm going to leave this open for followup work: Files, Pastes, Maniphest should get indexes; and we should replace the powerful systems in Projects and People.

As general infrastructure cleanup, I would like to split the existing SearchEngine and DestructionEngine components apart...
As part of this cleanup, we should also fix T9890.

Custom fields (and paths, too) can now be read with owners.search and written with owners.edit. There's a description of a more complex edit (against paths) here, but the same general workflow applies to examining and updating custom fields:

Maybe IndexEngine is a better name than FulltextEngine.

Upshot is that this seems very promising to me. I think the pathway forward here is something like:

Okay, here's a query script:

I created an ngrams table like this:

Try the dedicated table on the files dataset and see how happy MySQL is about that (if it's better but still not great, we might still do this in conjunction with bigrams/trigrams).

I think this stuff is basically in good shape, I'll follow up on the Phame stuff in T9897 and the arc stuff in T7715.

Thanks for thinking through all of these! Let me know if there is anything I can help with.

Yes, but I have some hesitance around adding "search for a string in another string" fields without building better infrastructure first. There's some discussion in D14411#161139.

Ok, got it. Do you think it's reasonable to search using a package name?

We don't check that the path actually exists -- you might be searching for a deleted path that used to exist, or the repository might have a million branches and it only exists on one, and you might have a thousand different repositories too.

You are right for the cases you described. But the case I mentinoed is that /src/infrastructure/PhabricatorEditor.php doesn't exist in both Arcanist and libutil.

That result looks correct to me -- if a package includes "/", that means it includes everything under "/" too. So if you search for /x/y/z.cpp, any package that owns /, /x/, /x/y/ or /x/y/z.cpp will be returned, since any package owning a parent also owns the path itself.

In T9964#148566, @epriestley wrote:

I can't reproduce that. Here's a search using "Path", which seems to work correctly:

Can you give me more details about how to reproduce the issue you're seeing?

I can't reproduce that. Here's a search using "Path", which seems to work correctly:

You might already know, but I noticed that the owners search is broken if I use "path" instead of "Repositories" to query. Also it would be great if we can use the package name to search.

Thanks @epriestley, much appreciated!

No problem -- it's easier for us to merge duplicates than split tasks apart, so it's not bad to err on the side of filing new tasks.

In T9946#148060, @epriestley wrote:

I'm going to merge this into T9491, since that's the existing task covering the primary issue here.

T7676 is also somewhat related.

I'm going to merge this into T9491, since that's the existing task covering the primary issue here.

At HEAD, you can now edit this field via the owners.edit Conduit API method.

I'm seeing this same problem if a single user is a member of two projects. That user can only accept the audit for one of the projects leaving it in this state.

Yeah, at least as written. You could tweak the logic or I can swap it for something else if that's easier.

The way to do multiple builds per package is to use a remarkup custom field and separate them with newlines, correct?

• The way to do multiple builds per package is to use a remarkup custom field and separate them with newlines, correct?
• The herald rule should be "Always" instead of something to do with packages because CustomDifferentialRunPackageBuildsHeraldAction has sufficient logic of it's own?

After D14222, the updated P1860 should pass parameters properly. Here's a target getting a build parameter:

My plan is to allow parameterization at the build level; D13635 is an implementation of that but it has some other stuff mixed in and needs to be pulled apart a bit. I think this change is straightforward overall, though.

Quick progress update here: Owners packages now have configurable custom fields, so you can add one like this: