#metabrainz

elomatreb[m]: from a privacy perspective it's nice, because we don't store any personal information about the user until they very explicitly approve it

but yeah, I suspect that's more an implementation detail than a privacy-first decision originally

It's not like the email is exposed anywhere, so this would only be useful in the case of database breaches, right?

when are we moving to Meb accounts btw

when we finish implementation

I have a suggestion: that the "username" is one thing, but "displayname for each project" can be different things (also that (because most email providers can do this) emails can be like, main one is foobar@whatever.cat and lb can be like foobar+YASS@whatever.cat etc. it will make it really easy for peopel to filter emails and the like)

i personally need this for community mail? (and if this was so, thne I could finally merge the accounts and weirdo siht with loggis and stuff that freso had to manually set up for me could be undone and stuff)

how many requests is that? 2? something about display name and something about email?

re: email, I suspect there are better ways that we can identify emails to show what project they come from, we can look into that

i mean ia have this ,and i'm sure others d othis as well

it'll be a problem for jira since my accountname was made ages ago

re: usernames, I think our preference has been to consolidate accounts and make sure we always keep the same username across sites. we'd have to look at this in more detail to see how complex it is to support

i mean , I understand that base username is the same. but i'd still like not to have to rename my bb username?

alastairp: Do you want to add anything to the draft https://github.com/metabrainz/mmd-schema/pull/30 or can we just rename it and merge?

yvanzo: as I mentioned, I've not actually tried to build the schema with those changes. do we want to try?

lucifer did build it already with very similar changes, see: https://github.com/metabrainz/mmd-schema/compar...

yes, I didn't see his branch until after I made this PR

[mmd-schema] 14alastair opened pull request #31 (03master…Remove-CVS-ID): Remove CVS ID https://github.com/metabrainz/mmd-schema/pull/31

The timestamp changes usually come from the build process.

in fact, lucifer and I both used a different artifact

perhaps a good idea to look into the difference between the two and pick the "most correct" one, let me finish what I'm working on now and I'll have a quick look

IIRC, jakarta is just the still open source Java 11 version of what used to be included in Java 8.

yes, that's what I understood when I looked into it

I’m trying to build your branch atm but I guess that I'll have to pick up jakarta indeed

the "updates" for new versions of Jakarta at https://stackoverflow.com/questions/52502189/ja... seem to indicate that lucifer's branch is more correct

(uses group-id jakarta.xml.bind instead of javax.xml.bind)

atj_mb: https://community.metabrainz.org/t/digital-rele... do you feel that makes sense for atisket?

yes I think so, although I'd call it "[digital]"

unfortunately I think that would probably result in some apoplectic editors wielding pitchforks

lmao atj_mb

zas: not off to a great start with minio - https://github.com/minio/minio/issues/9847

CatQuest: Would an e-mail header like `X-MetaBrainz-Project: ListenBrainz` in outgoing mails work for you for purposes of e-mail filtering?

atj: well, if we had a guideline saying "use this" then you could point at it :p

(if someone screams)

reosarevok: please add it 🙏🏻

I'm going to check the feedback. But I know bitmap was frustrated with the lists from a purely code/performance POV too, so

well, if it's negatively impacting MB then something has to be done

Freso: tbh I have no idea how to work with those, but I'm sure others would welcome that

you would create a rule to filter by the value of that header in your email client

🤷

what I already have is a multitude of filters to put things in various folders, i'm not using gmail

I'd *prefer* strongly not having to faff about which changig a lot of these.. but I mean, these are prefrences

you asked for something to help you with mail filtering earlier though?

...

no, that was a reply to talk about centering oauths and such and what I'd suggest for emails to different projects

I suspect that would be workable with your system, but it's certainly less user-friendly than just the mail+substring@ option

yes

having both seems ideal

It's also a lot easier for us to support though :p

there's that

But when we're implementing the single user thing then we should keep an eye for workable ways of doing this nicely. It's possible it'd be as easy as making sure all our BB email comes from a whatever@bookbrainz.org account, but :p

(which would also make it fairly trivial to filter)

But dunno, we'll see when we're closer to getting there, I guess

sure

but it also relis on jira, communty, wiki, etc also following this

yes

I'm already having ot faff about with trying ot sort inst tickets seprate from the other jira tickets :D

would be great if there was some spesific project .. what called it, e-mail header thing for each project

infact that woudl be ideal

Well, that seems more complicated because it's all of it Jira code sending it so it'd depend on Jira allowing that :) But BB code vs MB code etc is probably easier

true

Of course, we have no idea how long Jira will even work fine for us :/ But another thing we'll get to when we have to get to it

now we just need the ability to actually *mail* bb-review notes

BugtrackerBrainz. called it

..

BugBrainz

YASS let's goooo

It's a *lot* of work to make a quality bug tracker :)

(I'd use BugBrainz though. But I guess that's already iNaturalist :p )

:D

I mean, this all feels exactly like the fingerprinting thing, and I say "make our own" and people was like "ack no, too much work/other reasons/etc" and I was like "..." and lukz was like "tadaaa acoustid.org"

Yeah, but it's just it's not even music related :)

It's a very general thing a lot, lot, lot of companies need and use, so there's good options out there - it's just annoying because they're... different options, and require changing stuff a lot and getting used to them

(vs fingerprinting, where it was more like "there's nothing out there which doesn't suck and all of it keeps dying on us")

In fact Jira is not dying, it's just going cloud-only, but I guess the main issue is we cannot use it with MB/MeB accounts if we use the cloud version?

my point, is. that we we do make this, then it is an intensley marketable thing, fully customisable "crack-marketingsceme" open bug tracker is sure to be something others would want, and bigger uppers would want to pay for

aha

Yes, that's perfectly true. It's just that we'd probably need the whole team to work on it, and if it works, then we'd be "the ticket tracker company" rather than "the metadata geeks company" :p

at the end of the day, nobody wants to write a bug tracker, and it is way more complex than you might imagine

I really don't want MeB to become a bug tracker company, *even* if we turned out to be very god at it :)

I mean personally, i care not about meb account beause my jira ting predates the mb-oauth by like what a decade?

*good

sure

Yeah, me too, but I guess the idea is that it makes it a lot easier for people to report bugs? :)

hm

Honestly, if the choice was "let's stick to jira and not have single sign on there and just give people a detailed guide instead" I'd be fine with that

But there might be other issues with cloud jira I'm forgetting

was'nrt old, old ticet tracker (the one before jira) had "anon" ?

Jira had too

We had to deactivate it because it was getting spammed a lot

so, we dissabled this because spam?

did it have like.. captca ?

Heh, amusingly it still says

"Attention: Anonymous reporting has been disabled due to spam. As an anonymous user you are still able to browse the entirety of this bug tracker, however, we suggest you create an account for yourself to ensure efficient communication. Note that this account is separate from the main website, forums, and wiki accounts."

yvanzo: can you change that to say that they can log in with the main MB account?

.. I mean

we could *create* a spesific anonymus accountmaybe?

and tell people the pass on the page or something.. idk maybe bad hack

also, I'm not suggesting metabrainz be the "ticket tracker company" but that we uh.. suggest that this s needed to our illustrious community and see what happens in 5-10 years

The problem is the Jira thing is going away in like two years max :)

But really, we'll figure something out

true

as long as I don't like. lose the ability to name my projects silly things

reosarevok: Even using MB SSO means creating a new account.

Fair, but isn't it pretty much all automatic?

going away? I missed something?

Reading that I'd be like "oh, god, I have to fill in a ton of forms, nope" :)

idk to be honest, we're hosting it right?

Did I misremember that we need to move to cloud or whatnot in the next couple years? Maybe I did. In which case, dunno - yvanzo certainly knows more about that than I do!

will atalassian be like " you no can use jira anymore! >(" or something?

It isn't going to change anything about the need for creating an account.

yvanzo: if it's pretty trivial to make the new account with SSO, we could change it to something like "Note that this account is separate from the main website, forums, and wiki accounts, but you can easily create it based on your MusicBrainz account" :)

Or something?

yvanzo: hi, did you manage to get jaxb working? Otherwise anything I can help with?

sounds logical

Something that doesn't seem like a lot of annoying work. Unless it is a lot of annoying work still :D

i'm pretty sure it's only like a click of a button or two

[mmd-schema] 14alastair merged pull request #31 (03master…Remove-CVS-ID): Remove CVS ID https://github.com/metabrainz/mmd-schema/pull/31

alastairp: I mixed your branch with lucifer's one, and added my own salt. Have been as far as regenerating Java source.

Will have to test it with Solr 9 in mb-solr.

yvanzo: that sounds good then

(force pushed it)

reosarevok: re: SEARCH-686, do you think that it's OK to go ahead with our quick fix in https://github.com/metabrainz/mbsssss/pull/63 and add this additional ranking in a later PR?

SEARCH-686: Rank instrument families lower in search results https://tickets.metabrainz.org/browse/SEARCH-686

It probably would be fine, although it is probably a fairly quick fix to add the ranking too :) Are you planning to merge to test, or merge to release?

I think merging to continue converting to solr 9 is certainly fine, but ideally we'd implement this before we release that to prod?

the problem with adding the ranking is that it involves changes to sir (because it would be a computed field), and that's currently in a pending stage due to the sqlalchemy upgrade

we could make a point release of sir to bring this change in

My question remains :)

I believe that yvanzo's idea was to get solr 9 in testing, and then test solr cloud on a new cluster, and only then release it in prod

Are we planning to move to solr 9 first, then update sir to python 3?

(like, solr 9, release, python 3, release)

yes, I blieve his plan is to do solr 9 first, so that we can debug sir/sqlalchemy in the meantime

Ok. Well, we can probably live with this for now, but ideally we'd patch it relatively soon to avoid people picking the wrong instruments :)

Since it's a pain to fix violin family or whatever later

Likely Solr 9 first because we don't have a resolution in sight of SIR regressions.

one thing I didn't add to that issue was an example of the search results currently vs what it ends up as with the patch applied

Hmm, annoying. We have genre search also waiting on a sir update

in our experiments, the Family stayed lower than instruments of the same name just, as a result of the instrument names

reosarevok: good point

alastairp: ok, that's good to hear :) Then this might not be too problematic

yvanzo: what are your thoughts on the other mbsssss PRs in the context of solr 9?

to sir with updates~