#metabrainz

/

      • zas
        Note: keep in mind ws/3 will prolly be json-based (and ws/2 supports json already), so mbxml will need work anyway
      • Sophist-UK
        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.
      • adhawkins
        bitmap: Ok. I'll hold off then, if it helps?
      • bitmap
        sure
      • zas
        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
      • Sophist-UK
        Then if we want to add support for new metadata, we can make all the changes in the one .py file.
      • samj1912
        Sophist-UK part of the reason I am waiting for the summit before starting to work on mbxml related refactoring
      • Sophist-UK
        They would be plugins in the same way that CA is done using plugins i.e. internal.
      • samj1912
        It might just be useless by the time 2.0 reaches its first stable version
      • And we might have mbjson
      • Sophist-UK
        But that would not stop someone writing a new plugin.
      • samj1912
        Not sure what the plans are for a new WS
      • zas
        samj1912: none for now ;)
      • but preliminary discussions show we aren't fond of xml ;)
      • Sophist-UK
        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.
      • zas
        Sophist-UK: +1 to split actual picard preprocessing of mb data from mb data, currently this is a bit mixed up
      • Sophist-UK
        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).
      • Freso
        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?)
      • zas
        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
      • Sophist-UK
        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.
      • Freso
        I think that's fine.
      • samj1912
        I will help, since this is pretty close to my Gsoc phase 2 part.
      • Sophist-UK
        Great.
      • Freso
        Alright.
      • samj1912
        Wrap up and good night folks o/
      • Freso
        So that's tonight meeting settled? Are we on again next Tuesday, or are you set to go for a while samj1912? :)
      • Sophist-UK
        I still have my multi-level work paper that needs discussing.
      • samj1912
        I think I have enough to code for a a couple of weeks
      • Freso
        Oh, right.
      • Sophist-UK
        If we can meet one Tuesday in the next couple of weeks that would be good.
      • Freso
        samj1912: ^ ?
      • samj1912
        Next Tuesday for works paper?
      • zas
        I'm not against a Picard meeting on next tuesday, but we can make it shorter ?
      • Freso
        We could potentially also do it at a "regular" Monday meeting (the last few Mondays have been rather short).
      • samj1912
        Yes. I would also like that
      • zas
        but i think we should keep one per week
      • CatQuest
        +1
      • Freso
        So next Tuesday, 18:00–18:30 UTC
      • zas
        works for me
      • Sophist-UK
        This one has been quite short.
      • CatQuest
        yes please keep it as tuesday
      • Sophist-UK
        Works for me.
      • samj1912
        👍
      • CatQuest
        :D
      • samj1912
        Sophist-UK still an hour :p
      • Freso
        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.
      • samj1912
        And we had a clear agenda this time with almost 0 disagreements :p
      • Sophist-UK
        Doesn't matter.
      • Freso
        See you then!
      • samj1912
        Yo o/
      • Sophist-UK
        </bang>
      • CatQuest
        \o/
      • Freso
        Sophist-UK: ;)
      • CatQuest
        natta samj1912 !
      • Sophist-UK
        GN samj1912 - sleep well.
      • samj1912
        Freso you can skip the picard meeting notes, I think Sophist-UK 's doc can be used to append meeting notes to it
      • Freso
        samj1912: I think it's still nice to get them to the forums.
      • samj1912
        He had already recorded the last week's I think
      • CatQuest agrees
      • Okay :)
      • CatQuest
        but we can also put it in the doc :D
      • Freso
        (And I'm already half done with last week's.)
      • samj1912
        Nn 😴
      • Freso
        Natta :)
      • CatQuest
        natta!
      • CatQuest off into the rain to picup lego bought from ebay to accent the lego pirate chess set
      • Sophist-UK
        Last week's already in the doc - this weeks also.
      • CatQuest
        wtg Sophist-UK
      • Sophist-UK
        But could do with someone to check I got it all.
      • I will add a chatlog link too.
      • Freso
        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.
      • Sophist-UK
        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.
      • madmouser1 has quit
      • Ok - write-up finished for people to review for accuracy.
      • just_me has quit
      • bitmap
        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
      • just_me joined the channel
      • MajorLurker has quit
      • adhawkins
        bitmap: Can I just add that as an origin, and then checkout the branch?
      • bitmap
        yeah, that should work
      • git fetch mwiencek && git checkout node-fixes
      • adhawkins
        So what now, npm install, then try compiling again?
      • bitmap
        right
      • adhawkins
        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
      • bitmap
        safe to ignore for now, I think
      • adhawkins
      • bitmap
        though old versions of npm behave stangely if you don't rm -rf node_modules first
      • adhawkins
        Ok. Resources have compiled. Should I clear out the node modules and retry before continuing?
      • bitmap
        maybe see if things work first though
      • you can continue & try that if you're getting more errors
      • adhawkins
        Ok, running up the server now.
      • hibiscuskazeneko joined the channel
      • Just trying the server.
      • Ok, home page has loaded. Let me check web service.
      • Yep, looks good! :)
      • bitmap
        excellent!
      • I'll submit a PR then. thanks for testing
      • adhawkins
        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?
      • github joined the channel
      • github
        [musicbrainz-server] mwiencek opened pull request #510: Node 0.12 fixes (master...node-fixes) https://git.io/v9Nya
      • github has left the channel
      • bitmap
        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
      • adhawkins
        I'll nuke it, saves causing issue later.
      • Would you recommend a node update too while I'm at it?
      • bitmap
        the latest versions of npm improved a lot in this regard, I think
      • SothoTalKer
        pfft and samj1912 is gone again
      • bitmap
        definitely, might prevent more issues down the road
      • adhawkins
        Ok. Just go for v6? Or go for latest?
      • bitmap
        the latest is stable for me, if you can find packages for it, otherwise v6 should work just as well
      • adhawkins
        I'll go with 6. Would prefer 'stable' over bleeding edge.
      • Wish me luck, I'm going in :)
      • bitmap
        we'll support v6 at least as long as it's LTS
      • good luck :)
      • adhawkins
        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?
      • bitmap
        nuke first
      • adhawkins
        Ok
      • rdswift has quit
      • bitmap
        sometimes it decides to install different things depending on what node version you have
      • adhawkins
        Ok.
      • Oooh...pretty.
      • Ok. Done. Couple of warnings for optional stuff.
      • bitmap
        yeah, I get that too. doesn't affect the server at least
      • adhawkins
        Ok cool.
      • just_me is now known as rdswift
      • Are those errors logged at server startup expected?
      • rdswift has quit
      • bitmap
        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
      • rdswift joined the channel
      • basically it should just log errors to the console instead of sending them to Sentry
      • adhawkins
        Ok cool. As long as you're not concerned, neither am I :)