#metabrainz

Note: keep in mind ws/3 will prolly be json-based (and ws/2 supports json already), so mbxml will need work anyway

If we did that, we culd then centralise everything to do with that metadata into the one file - by creating apis to allow them to add metadata definitions and mappings for each format.

So, the release mbxml plugin would define the metadata tags it will populate, and tell each format what the mapping is from those into file tags.

bitmap: Ok. I'll hold off then, if it helps?

sure

Sophist-UK: picard plugins are python modules, so .. it is basically a code rework and clean up, i don't like the idea of making core functionnalities "plugins", but defining proper API and better use of modules is fine

Then if we want to add support for new metadata, we can make all the changes in the one .py file.

Sophist-UK part of the reason I am waiting for the summit before starting to work on mbxml related refactoring

They would be plugins in the same way that CA is done using plugins i.e. internal.

It might just be useless by the time 2.0 reaches its first stable version

And we might have mbjson

But that would not stop someone writing a new plugin.

Not sure what the plans are for a new WS

samj1912: none for now ;)

but preliminary discussions show we aren't fond of xml ;)

My thoughts at present are we should not rewrite the xml handling code - just break it up into pieces, and centralise. I think it will make a switch to json easier when it comes.

We could switch to ws2 json if we want to put the effort into it.

Sophist-UK: +1 to split actual picard preprocessing of mb data from mb data, currently this is a bit mixed up

And my profiling of Picard shows that the heaviest CPU load is in reading XML into Picard. I am assuming that json will be less processor intensive (esp if we can use a C-based Python standard module to do it).

So I think the summary is that Sophist-UK can go ahead with their proposed changes? (And I guess we can discuss more specifically in the PR?)

yes, if the goal is to split xml-related stuff from the rest

we'll need it at some point anyway

and in the process i guess a lot of code cleanup will happen

so that's a go from me

I won't have the time to code a switch from xml to json. But I might have time to split mbxml and create the format apis.

I think that's fine.

I will help, since this is pretty close to my Gsoc phase 2 part.

Great.

Alright.

Wrap up and good night folks o/

So that's tonight meeting settled? Are we on again next Tuesday, or are you set to go for a while samj1912? :)

I still have my multi-level work paper that needs discussing.

I think I have enough to code for a a couple of weeks

Oh, right.

If we can meet one Tuesday in the next couple of weeks that would be good.

samj1912: ^ ?

Next Tuesday for works paper?

I'm not against a Picard meeting on next tuesday, but we can make it shorter ?

We could potentially also do it at a "regular" Monday meeting (the last few Mondays have been rather short).

Yes. I would also like that

but i think we should keep one per week

+1

So next Tuesday, 18:00–18:30 UTC

works for me

This one has been quite short.

yes please keep it as tuesday

Works for me.

👍

:D

Sophist-UK still an hour :p

Sophist-UK: It's been almost an hour, which is our regular meeting time limit. :)

Alright. Next Picard meeting will be next Tuesday, 18:00–18:30 UTC.

And we had a clear agenda this time with almost 0 disagreements :p

Doesn't matter.

See you then!

Yo o/

</bang>

\o/

Sophist-UK: ;)

natta samj1912 !

GN samj1912 - sleep well.

Freso you can skip the picard meeting notes, I think Sophist-UK 's doc can be used to append meeting notes to it

samj1912: I think it's still nice to get them to the forums.

He had already recorded the last week's I think

Okay :)

but we can also put it in the doc :D

(And I'm already half done with last week's.)

Nn 😴

Natta :)

natta!

Last week's already in the doc - this weeks also.

wtg Sophist-UK

But could do with someone to check I got it all.

I will add a chatlog link too.

Sophist-UK: "Next meeting: Tuesday, starting 1hr earlier (to avoid v. late meeting for attendees in India) for 2hrs" - we specifically agreed on 1 hour, and a clearer agenda.

Ok. Clearer agenda I remember - but I was under the impression we had agree on an earlier start to allow for a longer meeting. But I am equally fine with 1hr.

Ok - write-up finished for people to review for accuracy.

adhawkins: I pushed some fixes there if you want to grab that branch https://github.com/mwiencek/musicbrainz-server/...

if they work for you I'll open a PR

bitmap: Can I just add that as an origin, and then checkout the branch?

yeah, that should work

git remote add mwiencek https://github.com/mwiencek/musicbrainz-server.git

git fetch mwiencek && git checkout node-fixes

So what now, npm install, then try compiling again?

right

Warning about lots of unmet dependencies, but says it will load anyway. Should I be concerned?

e.g. npm WARN unmet dependency /home/mbserver/musicbrainz-server/node_modules/gulp-watch requires glob@'^5.0.13'; but will load

npm WARN unmet dependency /home/mbserver/musicbrainz-server/node_modules/glob,

npm WARN unmet dependency which is version 4.5.3

safe to ignore for now, I think

Full list: http://paste.debian.net/932764/

though old versions of npm behave stangely if you don't rm -rf node_modules first

Ok. Resources have compiled. Should I clear out the node modules and retry before continuing?

maybe see if things work first though

you can continue & try that if you're getting more errors

Ok, running up the server now.

Output at startup: http://paste.debian.net/932765/

Just trying the server.

Ok, home page has loaded. Let me check web service.

Yep, looks good! :)

excellent!

I'll submit a PR then. thanks for testing

No worries, always happy to help out.

I'll keep an eye out for further server updates, then test as and when it's in the 'official' source.

Think it's best to nuke the node modules and start again?

[musicbrainz-server] mwiencek opened pull request #510: Node 0.12 fixes (master...node-fixes) https://git.io/v9Nya

adhawkins: usually best to nuke it, if you don't mind waiting for it to pull everything again. but sometimes it works okay if you don't

I'll nuke it, saves causing issue later.

Would you recommend a node update too while I'm at it?

the latest versions of npm improved a lot in this regard, I think

pfft and samj1912 is gone again

definitely, might prevent more issues down the road

Ok. Just go for v6? Or go for latest?

the latest is stable for me, if you can find packages for it, otherwise v6 should work just as well

I'll go with 6. Would prefer 'stable' over bleeding edge.

Wish me luck, I'm going in :)

we'll support v6 at least as long as it's LTS

good luck :)

Will that update npm too?

It's now reporting 3.10.10

Node is 6.10.3

bitmap: Just npm install now? Or nuke the directory first?

nuke first

Ok

Ok.

Oooh...pretty.

Ok. Done. Couple of warnings for optional stuff.

yeah, I get that too. doesn't affect the server at least

Ok cool.

Are those errors logged at server startup expected?

kind of, the perl ones I see everywhere but I believe are harmless warnings we can't control

the "alert: no DSN provided" ones are expected & harmless, but we should probably silence them since they're annoying

basically it should just log errors to the console instead of sending them to Sentry

Ok cool. As long as you're not concerned, neither am I :)