I marked D14023 as resolving this since I think I took care of most of the really silly/old stuff and this now works in a fairly reasonable way, at least for the most part.

That fixes the link thing, if anyone runs into the other thing we can fix it once we have a repor.

When you say it "does not appear to do anything", do you mean that the click is completely swallowed? Or the menu closes but nothing else happens? Or the menu closes and the input is updated (this is the expected behavior), but you aren't taken anywhere and expected to be taken somewhere?

(Pretty sure this isn't related to T5263.)

I can't view those links and can't reproduce this locally:

Ah, thanks! That use case makes sense to me too.

For binding builds to packages to work I think they need to overlap. For example: Run the 'Super Sweet Selinium Spaces Tests' if src/applications/spaces OR src/infrastructure changes, but src/infrastructure is also a trigger for other packages.

I think the answer for "A" and "B" is almost certainly that both packages still own the file, and the more specific claim made by "B" does not invalidate the claim made by "A". In particular, "A" can add paths in "B" with 'exclude' rules if the intent is truly for "B" to exclusively own the files.

@epriestley, thanks for consolidating my request into this task! Some comments: a person could be an owner of multiple packages, it would be better to indicate all files with their package names instead of only indicate the files you are an owner of; We actually don't need to put the package name on each line, we can group the files by package and put the package name to each group. One benefit of indicating all files with package names is everybody see the same, there will be less confusion (in most cases we can assume everybody knows if s/he is an owner of a package).

Mock from @nickz:

I'm just going to merge this into T3980, since projects can be owners and that would allow projects to have dynamic membership. I don't plan to implement a separate mechanism in Owners.

I plan to just improve documentation to address this.

Yeah, you should be good to go -- I don't think there are any surprises here. The old code just nuked the actual data since it was written in like 1950.

Maybe I can do dis.

monospaced text

We could maybe do exotic monograms (π) or multicharacter monograms (PKG123) but I generally like T5378 first, at least.

I suppose that makes sense. I really like having the popup box when you hover over monogram references but I suppose that T5378 could fix this as well.

(We only have ~30 reasonable monograms, most of which are used, and it's rare to need to refer to a package.)

Oh :(

Yes.