#metabrainz

[musicbrainz-server] mwiencek opened pull request #619: Add an Object.assign polyfill for IE11 (master...object-assign-polyfill) https://git.io/vAwav

zas: you can merge 846 if you are finished with it

well, i'm still wondering about it, and i would like it to be tested on win/mac

also i wonder about those "defaults", because they are set once, on first startup, but those paths may change after

zas, what do you mean about testing on windows and osx?

It works as intended.

i was thinking about something else: defaulting to None, and if not set, use "currrent" path returned by those methods (at runtime)

if you see what i mean ...

for sure, it is already better than defaulting to "." ...

if the user didn't set any value, i think we should keep it dynamic

for example, if Picard is first started with no existing "Music" dir, it will prolly fallback on user's home (or whatever). And subsequent starts will use this value, even if, in the meantime, an actual "Music" directory is created.

But the patch would be more complex

is that likely to happen? AFAIK all users on windows and linux usually start with a music directory somewhere.

I don't think we need to overthink this that much. The defaults are nice.

Yeah, same for osx.

Mineo, samj1912 : ok, i'm fine with it ;)

Mineo: since you are here, can we discuss about plugins ?

[picard] zas closed pull request #846: Set default paths to standard locations (master...stdpaths) https://git.io/vAa1p

metabrainz/picard#3208 (master - e51d998 : Laurent Monin): The build passed.

Change view : https://github.com/metabrainz/picard/compare/99...

Build details : https://travis-ci.org/metabrainz/picard/builds/...

Mineo: ?

give me 5 minutes

ok, np ;)

ok

samj1912: are you here too ?

o/

but the code is over complicated, we still don't support i18n properly, and python imp module is getting deprecated

also we have no *real* plugin API (no way to enforce it), plugin authors use whatever they want, we mitigate things having plugin API versions

the plugin webservice on picard's website isn't that great, because it requires sync with plugin sources, and it is unclear what they are (picard-plugins repo is one)

I thought that was the only one?

as far as PW is concerned

samj1912: nope, we can't really force plugin authors to manage their code within this repo.

so, how can we improve things ?

well a better way would be to have it how other stores have it

industry tested methods should be the best

for how many plugins is this a problem? the only one I can think of right now is the classical extras one

metabrainz/picard#3208 (master - e51d998 : Laurent Monin): The build passed.

Change view : https://github.com/metabrainz/picard/compare/99...

Build details : https://travis-ci.org/metabrainz/picard/builds/...

keep a simple way to for authors to upload new versions and store that latest per major version

we can also enforce plugin metadata this way

ok, let say someone is writing a plugin, he's using bitbucket, and wants to make it available to all picard users, how does he proceed ?

downloads a release zip and uploads it with the right manifest, if the manifest does not exist, PW can provide a simple form to fill it in

we also have the now defunct picard-plugin-tools repo if we want to make use of that

upload it where ?

PW

how?

should we provide a "register your plugin" page ?

well, we will have to add the concept of accounts, preferably via mb oauth and then lead the dev to a plugin upload dashboard

we can approve the first version of a plugin(via an admin dashboard) and then let the dev upload revisions without approval

do we really need to go this way for <30 plugins ?

ofc we will also have the right to take down any plugin

well currently it is 30, this will just make it easier for new devs to make plugins

Mineo: what do you think ?

plus I have seen plugin repos with lesser plugins

zas: given the frequency of changes to our plugins, I think this is solving a problem that doesn't exist

Mineo: elaborate please

well, most of our plugins don't see any development anymore at all and if, it's usually some small bug fix from someone in MeB's inner circle

I think a major reason for that is a lack of proper plugin dev docs. I see a lot of community threads/tickets created for something that can easily be solved by a plugin

but it sounds like the problem we're trying to solve at the moment is making it easier for external contributors to get their plugins into picards plugin list. I get that it's a chicken and egg problem - there's no way to do that at the moment, so we don't know how many people would use it

yes, but imho that's the result of: lack of documentation, lack of clear path to distribute, constraints resulting from single repo + PR reviews + lack of reviewers, etc...

maybe a plugin request category in discourse to start it off and better documentation/contribution tools

but I don't know, I'd say even if we invest some time into making a nice plugin management site where everyone can register etc. there won't be plugin authors popping up left and right

but this way we can mitigate plugin issues slightly, if someone has a problem with a plugin they can simply contact author in the plugin info on PW

currently the way plugin issues are handled are also bad

ok, i think having a plugin registration page, requiring auth, etc, is overkill, i'm thinking about another approach, requiring only access to a zip somewhere (this can be a github "release"), and managing plugin "sources": remote and/or local, website could jjust display list of plugins from known "sources"

let me explain