Bugzilla

(In reply to Rob Lemley [:rjl] from comment #0)
> Also, there is now Rust code being added to Thunderbird. I'd like to get the semantic analysis going for Rust as well as C++.

Do you know if Thunderbird is able to commit to contributing an ongoing level of engineering and maintenance resources to searchfox?  Indexing comm-central has been pretty cheap[1]/painless since it's ~fulltext and not too much of a maintenance burden without the semantic data since there's been little that could break[2] and we didn't really address the weird tree/build setup.  Semantic support would significantly change that calculus, especially in terms of upcoming hyperblame/phabricator-integration features where the tree complications would be a major concern.

If it's not possible to commit ongoing resources but a higher quality of searchfox experience is desired, it might make sense for Thunderbird to stand up its own searchfox instance that doesn't track the mozsearch trunk but instead updates its tracking branch periodically, like the Igalia webkit search used to do.

1: More so for the comm- trees that don't have the mozilla/ checkout; the mozilla/ checkout in comm-central is a concern but currently status quo.

2: The caveat is that because we always try and run JS analysis and I implemented a sort of quality ratchet there in fact was some JS stuff I've had to deal with, but

(In reply to Rob Lemley [:rjl] from comment #0)
> Also, there is now Rust code being added to Thunderbird. I'd like to get the semantic analysis going for Rust as well as C++.

Do you know if Thunderbird is able to commit to contributing an ongoing level of engineering and maintenance resources to searchfox?  Indexing comm-central has been pretty cheap[1]/painless since it's ~only fulltext and not too much of a maintenance burden without the semantic data since there's been little that could break[2] and we didn't really address the weird tree/build setup.  Semantic support would significantly change that calculus, especially in terms of upcoming hyperblame/phabricator-integration features where the tree complications would be a major concern.

If it's not possible to commit ongoing resources but a higher quality of searchfox experience is desired, it might make sense for Thunderbird to stand up its own searchfox instance that doesn't track the mozsearch trunk but instead updates its tracking branch periodically, like the Igalia webkit search used to do.

1: More so for the comm- trees that don't have the mozilla/ checkout; the mozilla/ checkout in comm-central is a concern but currently status quo.

2: The caveat is that because we always try and run JS analysis and I implemented a sort of quality ratchet there in fact was some JS stuff I've had to deal with, but

(In reply to Rob Lemley [:rjl] from comment #0)
> Also, there is now Rust code being added to Thunderbird. I'd like to get the semantic analysis going for Rust as well as C++.

Do you know if Thunderbird is able to commit to contributing an ongoing level of engineering and maintenance resources to searchfox?  Indexing comm-central has been pretty cheap[1]/painless since it's ~only fulltext and not too much of a maintenance burden without the semantic data since there's been little that could break[2] and we didn't really address the weird tree/build setup.  Semantic support would significantly change that calculus, especially in terms of upcoming hyperblame/phabricator-integration features where the tree complications would be a major concern.

If it's not possible to commit ongoing resources but a higher quality of searchfox experience is desired, it might make sense for Thunderbird to stand up its own searchfox instance that doesn't track the mozsearch trunk but instead updates its tracking branch periodically, like the Igalia webkit search used to do.

1: More so for the comm- trees that don't have the mozilla/ checkout; the mozilla/ checkout in comm-central is a concern but currently status quo.

2: The caveat is that because we always try and run JS analysis and I implemented a sort of quality ratchet there in fact was some JS stuff I've had to deal with, but otherwise not too bad.