> 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 On Wed, Oct 4, 2023 at 4:26 AM Kimmo Virtanen <kimmo.virta...@gmail.com> wrote: > Hi Vivian, > > First, thank you for maintaining the Quarry. > > A couple of questions from a technical perspective. > > 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? > > 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. > > 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. > > Br, > -- Kimmo Virtanen, Zache > > > _______________________________________________ > Cloud mailing list -- cloud@lists.wikimedia.org > List information: > https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/ > -- *Vivian Rook (They/Them)* Site Reliability Engineer Wikimedia Foundation <https://wikimediafoundation.org/>
_______________________________________________ Cloud mailing list -- cloud@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/
