#metabrainz

ruaok: you know why hetzner does not charge VAT for foreign companies? :x

not sure, but I assumed that VAT doesn't apply to some countries... like the US because its speshul

for companies from the EU the reverse charge system applies, but i don't know the details of the contract of yours, so i can only guess :D

sounds right.

works for us. :)

if you had to provide a valid VAT ID from spain then that is what is used.

we're not doing business in spain, so no.

it's straight from the US, right?

yep.

oh well, i don't know how that works then. :)

beautifully. :)

that i hope.

i did not expect google to be so expensive, and that you have to pay extra for bandwidth... meh!

it was a shocker.

hetzner might be doable.

cloud that is

i mean come on, hardware is deadly cheap in the US.

we stupid europeans pay like 1/3 more compared to the US :|

hah. try being in a stonequarry like norway. we pay extra extra import tax ontop of the already exorbinant prices for things like hardware

2TB ext hardrive? that costs ridicolous atleast 1K nok

if not 2

yvanzo: ping

chhavi_: I read the gameplan -- I need to touch base with yvanzo and bitmap, then we can chat about it.

ruaok: pong

moin!

I'm wondering if you have a feel for how our migration to react is going?

how far along are we?

we moved only a few bits

which ones? are they live?

bitmap is still addressing issues such as with gh:MBS#599

MBS-9599, MBS-9600, MBS-9603: Support other gettext domains in the JS: https://github.com/metabrainz/musicbrainz-serve...

Sidebar atings and tags are live React bits.

+r(atings)

and fixing #599 will unblock pushing out more things?

I worked on moving macros to React too.

Yes, almost every page using localization will be unblocked with #599

any idea of how many pages we've done the work for that will be releasable or near releasable one #599 is taken care of?

Okayy :)

No, there are many macros that need to be replaced as well, but that is a root issue for migrating even macros.

ohh, fun. circular dependencies.

I'm trying to figure out how to manage the react move, the UX cleanup and schema change in the next few months.

clearly the react move needs to be done before we can really dive deeper into the UX stuff.

hmmm... no, #599 unlocks l/lp/ln macros which are used pretty much everywhere. Then, we have to migrate other root macros (paginator, and so on), then we have full pages.

Only basic pages can be moved soon, such as instrument list, isrcs, iswcs (by spellew).

migrating other root macros... 1 week? 1 month? 6 months?

I'm wondering if moving something like the artist page could also give it a new UX, but I fear that is going to be too disruptive to the flow our our UI.

and doing it in separate passes will be duplication of work.

More than 1 month for sure.

ok

chhavi_: a picture is emerging now. :)

For every bit we move to React, we would like to write Selenium tests as well.

makes sense.

I'm going to think out loud for a moment....

chhavi_, yvanzo: see what you think of this.

1. we delay the schema change to autumn.

2. While bitmap and yvanzo work to move to react, chhavi_ lines up all the design and componentization.

3. once both the UX prep and the move to react are done, we call "all hands on deck." every engineer works on the UX improvements to MB. we stop doing releases on MB, except for critical bugs.

4. once we finish all non-edit pages we release and resume a release schedule.

this approach serves two purposes:

1. For a while we're all working on the UX stuff. chhavi_ plays master of ceremony for this process. we learn and move MB along.

2. It is less disruptive to non-editors. We'll end up with a multiple personality disorder site, where edit pages are old, and non-edit pages are modern.

The theory is that our editors are more able to cope with #2 than the general public.

depending on schedule we can then see if we focus on an autumn schema change or continue with edit page UX migration.

not sure how realistic this process is. but it is a starting point for us to think about.

Sounds good to me, from my limited knowledge :p :)

I think the most important thing for me is that you're not actually doing any of the nitty gritty work. but really more mastermind that moves the whole process along.

we'll need to see how GSoC fits into this, because you do need to write code for it.

first I need to get bitmaps feedback, then we can see.

Just 1 thing I would want to do before we switch gears to UX is to scale our postgres and setup our read replica properly.

that is becoming important, yes.

maybe you can focus on that while the react train is moving.

and did you see the spreadsheet about hosting costs?

Yup i did

going full cloud is vastly more expensive than hetzner.

hetzner cloud might be interesting, zas and I will examine.

Cool, oh and did you also compare with aws? I thought that might be cheaper. Not sure though.

AWS was not directly in there as google cloud was something we could get some support from google on.

but they are priced in similar ways.

certainly not different enough to dislodge hetzner from the logical choice.

ruaok: I agree about focusing on requirements for UX stuff. While I dislike delaying schema change once again, I am not sure we can make use of it before the autumn anyway, except if it helps improving UX for non-editors.

are there things schema-change wise that are pressing for us to address?

Schema change tickets I reviewed til now are all for editors, e.g. MBS-5387

MBS-5387: ACs being edited aren't marked as having pending edits on the aliases tab https://tickets.metabrainz.org/browse/MBS-5387

There is a long-standing request for box set support.

that is more than a decade old. it can wait another 6 months. lol.

:)

I'm not opposed to doing a schema change release if it is a bug fixes that are good for the community.

but things like box sets? I think we should not tackle new features.

maybe if we set the artificial limit of 2 weeks of engineering time for the schema change release that might be ok.

Another example is merging subscriptions with collections, but it impacts UX for editors only.

Ok, I will review these with bitmap.

For the rest, I am all in.

and making UX changes before a big UX revamp might be a waste of time.

ok, great.

I think what chhavi_ is doing is great and we need to clear our schedule to make this happen.

we all want it and we're in a near perfect position to finally get it done.

the react thing is the big blocker because that has significant impact on our hosting.

Leo_Verto: I just messed a bit with BrainzBot's permissions. Can you make it PART and JOIN the channel?

iliekcomputers: remind me, did you find out anything more about cron?

Freso: did you voice it?

Leo_Verto: Yeah. Should protect it from accidentally getting caught by Sigyn.

(If it's ever needed for something.)

that might be interesting in the future, then we wouldn't need to store user permissions internally