> First, based on GitHub requirements.txt the library versions used
in the app are older than the latest ones, and T169452 also hints at
growing technical debt in terms of updating code. However, are there
known blockers for updating them? Ie. Does Quarry use something
abandoned and blocks updating others, or is there something else that
would require a rewrite? Or is it that updating is expected to work, but
it just takes someone's time to do it?
That's very much so the case. The primary lacking detail is time to get things updated. Should anyone want to do so, they are welcome to. There are no known abandoned or otherwise overtly problematic things in quarry. And usually the effort in upgrading quarry is in fussing with calls that changed syntax or the like between versions. There are some weird things in quarry, namely how the db is structured. I find it unintuitive that there isn't a unique ID/query, rather they're called through several different tables by different ids, this doesn't stop quarry from working, just one of the things that in my mind needs fixed. In terms of debt, it's covered in the quarry board (
https://phabricator.wikimedia.org/project/view/800/), there are, reasonable, desires that the UI be updated to be more intuitive, or offer a query builder, that the database selector shouldn't be offering databases that don't exist. Many features and bug fixes are requested.
> Secondly, is there
something that would prevent moving it to Toolforge? I am unsure if it
would be a viable solution, but it would reduce the maintenance burden
if volunteers would maintain it, so I am asking what would be blocking
it.
Nothing really, though I think that would be more complicated than leaving it in place. In concept it could be left largely as is, so long as someone wants to do OS and resulting python/library upgrades, quarry could continue on. If you really wanted to, it would need re-written to fit into the toolforge framework, I'm not quite sure what that would entail.
> Also, it would be worth creating a
Phabricator ticket for moving maintenance to the next person, describing
what it would require and how it could be done. I do not know if there
would be anyone, but for example, my use case for Quarry is sharing SQL
queries and query results with wikieditors, and as long results aren't
cached and reading the results requires OAUTH-login Superset doesn't
work.
Opening a ticket for a handoff is welcome. It's mostly as you mentioned, it's just time to manage upgrades. Which I've been told to redirect to other efforts. You're welcome to open one and I can update it if desired, though I think I'll wait for a maintainer to step forward before I open such a ticket.
Caching of results is one of the features that superset and other services that I was investigating do not offer. It follows the idea that old data is less valuable than fresh data. You can share queries through things like charts, and those can be re-run as needed to refresh the data for them. Though the results themselves don't stay around for very long in superset.
In terms of OAUTH
https://phabricator.wikimedia.org/T336522 is to offer the ability to view without login. When I have some time for that I will see how I can get it to allow read/refresh access to anonymous users. (I say above that I'm working on superset, when in reality I'm being redirected to openstack)
Vivian Rook
