for flask testing, i guess we find another testing lib or fork and fix the stuff we need. the repo seems unmaintained so submitting patches there is likely not useful.
alastairp
lucifer: pip wasn't happy with upgrading just flask - there were quite a number of dependencies that we have that weren't compatible and so I had to update them too
monkey: hi, this dropdown (top right) is from a recent PR by Ansh. Any feedback on it? Specifically, if it's currently set to "newest", should the option in the dropdown be selected/disabled in any way?
akshaaatt: aerozol: your feedback on this welcome too!
CatQuest has quit
monkey
alastairp, Ansh: yes, I think showing the currently selected option (which is just adding the "active" css class if i'm not mistaken) would be useful
Not much other feedback, it's clear and the placement makes sense.
TOPIC: MetaBrainz Community and Development channel | MusicBrainz non-development: #musicbrainz | BookBrainz: #bookbrainz | Channel is logged; see https://musicbrainz.org/doc/IRC for details | Agenda: Reviews , Next meeting (Easter monday, alastair)
alastairp
monkey: thanks. only other change is to remove Popularity and replace with 'Most Popular' and 'Least Popular' (so that we have the matching ascending/descending options for that)
monkey
Yes, that sounds great
CatQuest joined the channel
riksucks: I'm around now
reosarevok
bitmap: oh, neat
Hopefully that will help
What's the loss compared with the usual one?
bitmap
it is way faster, but we lose the ability to customize how the strings are split before diffing (e.g. in some cases we use \s+ to implement word diffing)
reosarevok
Hmm
Would it make sense to use it only for annotations?
So, either pass a useFastDiff or call a different FastDiff component?
bitmap: I just thought it might be annoying to check len, but maybe not
Can you send a quick PR?
bitmap
sure
reosarevok
Ideally we'd release that today as well (with a quick test in beta to see nothing is broken) because the whole thing seems ridiculous at the moment
lucifer
mayhem: done
riksucks
Hi monkey, I wanted to ask, how do you guys plan to code the new frontend of LB
Should I be keeping something in mind while writing code, so that minimal changes need to be done
When migrating the codebase ofc (specially asking this so that I can choose the right drag and drop library for the soc project)
mayhem
lucifer: thanks!
CatQuest joined the channel
CatQuest has quit
CatQuest joined the channel
monkey
I don't think there's anything you would need to keep in mind, except maybe one: I think we will eventually end up with a sidebar to show the current user's followers on any page, so don't assume by default that the new functionality will only ever be used on the feed and home pages
No specific considerations with the drag&drop library.
I've been using react-sortable for playlist items but I don't think it does full drag/drop features
Some unsolicited advice on the side: probably best to start with and get a fully working end-to-end feature using the ListenCard context menu before doing anything drag&drop.
skelly37 joined the channel
akshaaatt
alastairp: I think the popularity fix you suggest makes sense. Other than that monkey has already suggested on how to make the selected option visible :)
Opening instrument for editing also creates links to all the instrument attributes, heh
(not from the list, but from its doc page)
I see two options: 1) have a check for id = 14 that shows a string for "Possible values" like "The possible values for this relationship can be seen from the {instrument list}"
2) have the possible values here, but block editing attributes if they have a root ID of 14 and not an id of 14
bitmap: what sounds better to you?
bitmap
both, I think? :) linking to /instruments makes sense but also making sure you can't edit them even if you type the url
that should be automatic i think. if you update the docstrings in flask endpoint, it gets updated in doc.
chinmay
Hi, I had a few questions that I posted late on Saturday. I'll post them again..
Hello @monkey @lucifer, I had a few doubts about send track project.
1. I am thinking that when a user clicks on "Recommend to user" option from the ListenCard component, they will see a modal with a populated list of users along with check boxes. What should this list populate?
a. Followers + Search box to search MusicBrainz users
b. Followers + Following + Search box
c. Followers only
d. Followers + Following only
2. When a recommendation is sent, should the sender see his sent recommendation in their feed? eg. "You recommended 'Song' to User B".
3. Should a third user (say User C) be able to see who recommended what track to whom? eg. "User A recommended 'Song' to User B".
I was mostly working on BookBrainz tickets. This week will be spent preparing for Easter. 🐟
"""
atj: Go!
(Others up: akshaaatt, reosarevok, yvanzo, lucifer, monkey, zas, bitmap, mayhem, alastairp, Freso – anyone else who want to give review, let me know ASAP!)
No atj?
akshaaatt: Go!
akshaaatt
Hi everyone!
Last week I continued work on MusicBrainz.
bitmap and I were also discussing how we could automate the release process, hence I started to understand jenkins and how we could potentially migrate to github actions.
This involved some research work.
Other than that I reviewed yellowhatpro's GSoC proposal and continued some work on the android app.
I also fixed some work in the Listenbrainz revamp work.
That's it for me! fin. Go reosarevok!
reosarevok
Hi!
Last week I worked on a bunch of tickets, including MBS-11178 (to document entity types and whatnot)