#metabrainz

Isn't Android 4 pretty ancient by now too?

that's the first complaint since months

Yes, it is

They also said it worked fine on Android 6 (and some Android 5 versions?), so it's probably due to Android 4's outdatedness.

Yup, the change i made fix it for them, and shouldn't have too much negative impact on our side

👍

basically instead of a neutral cert, i use mb.o's one, but it means non-SNI wouldn't work for other services we host (ie. lb)

that said, SNI is pretty standard now, i hope clients to support it in most cases, if not, i would prefer they upgrade ...

Mhm.

To finish, we had a bad event yesterday with a lot of load on MB website

not really identified the source, but the effects are showing weakness we need to work on

so i started to think about possible solutions, notably doing a proper rate limiting on websites too

the other axis, identified since months, is to improve MB website template system performance

because it doesn't scale well with traffic

fin.

yvanzo ?

hola

Last week, I have polished and pushed SQL part for entity attributes (UI still in progress), without any change to the existing work attributes, as announced. The outcome of discussions with bitmap, Freso and reosarevok is that languages won't be handled by entity attributes. Further potential improvements to attributes (such as short name for types and allowed values, free text for fallback

“Other” values…) better have to be postponed rather than rash.

zas: the template thing is part of the react stuff bitmap is working on, no?

reosarevok: yes, i think so ;)

reosarevok: absolutely :)

yep, though performance won't improve right away

yvanzo: definitely agree with a conservative first implementation :)

I've also investigated many recently reported issues by users and Sentry. Among those, a small bug in edit search led me to revisit and address the remaining subtasks of the long-awaited issue MBS-390. More edit search issues in progress.

MBS-390: Edit search is missing functionality compared to the pre-NGS edit search https://tickets.metabrainz.org/browse/MBS-390

Yay edit search

Almost all… Gentlecat?

:O

I'm still working on the indexer

the receiving part of triggers

(Only LordSputnik left. No one else has spoken up.)

woo

updates should be working, still need to implement deletion support

and test it all

I also reviewed GSoC proposals, helped people with that

LordSputnik: ?

So this week I worked on getting my ES6 update to bookbrainz-data finished - so we have our first published npm package https://www.npmjs.com/package/bookbrainz-data (build is failing due to minor linting errors)

I also updated -site not to break because it used to point to the master branch of bookbrainz-data, which changes :P It now uses the stable npm version

And the last couple of days I've nearly got all the ES6 updates to -site done too

Apart from that, I did a little bit of proposal reviewing today, and helping out justharshal

/fin

\o/

Alright. Thanks for all the updates. :)

Sophist-UK: picard-plugins & Travis

(If Sophist-UK is still around?)

Still here

Ok - first proposal is that we introduce unit tests into plugins and use Travis to check that plugins run ok.

+1

The unit tests would be simple Assert statements.

I don't see why anyone would be against that.

Sophist-UK: I think we can do better

We should also test the packaging scripts (e.g., generate.py etc.).

samj1912: great.

We can follow the botbot plugins templates for tests

And I don't see why we can't use the full range unittest(2) asserts.

+of

See ^

I think it would be nice to keep the tests with the plugins though.

Maybe esp. for plugins consisting of multiple files?

I don't spend nearly enough time on technology these days to keep up with what would be best. Its the concept I am proposing really.

Freso I think the above works?

A folder with test with test_plugin_name for the each plugin?

samj1912: Sure. Doesn't mean keeping tests next to plugins themselves would not also work. :)

Sophist-UK: I don't see why anyone would be against that concept.

If anyone is against that concept, please speak up now.

Are we enforcing this?

For each plugin?

I'd say no.

That is a good question. I wouldn't want to put people off writing plugins.

For now it's nice-to-have and something to strive towards.

For 2.0 at least for the plugins in the official repo, I think we should keep some minimum tests

samj1912: Compare https://github.com/metabrainz/picard-plugins/tr... and https://github.com/BotBotMe/botbot-plugins/tree...

samj1912: All botbot plugins are directly in one folder, all picard plugins are in their own subfolders.

So each subfolder could have test_pluginname.py in them.

Having every plugin run successfully on standard test data would be good. But obviously plugins are supposed to do something specific, and I think the tests for this should be encouraged but not mandatory.

(Or multiple test_….py's for more complicated plugins.)

(Or /plugins/pluginname/tests/...)

Sophist-UK: +1

Is there a ticket for this?

That brings us neatly to the second proposal....

To use Jira for Picard-Plugin tickets rather than Github issues.

Sophist-UK: That's a different topic. :)

And no - not yet - I will create one.

(Which we also discussed last week, but it's on schedule for this week too.)

reosarevok: Can we skip your DR and take this while Sophist-UK is around?

Um... which project should I create a ticket under.

Sophist-UK: https://github.com/metabrainz/picard-plugins/is... :)

Freso: k

Alright.

So, last week, we discussed this as well and decided to keep picard-plugins issues on GH.

But Sophist-UK wasn't here last week, so didn't have a chance to present their case.

So, Sophist-UK, take it away. :)

My thinking here is that the quality of Picard Plugins reflects on the quality of Picard. And often plugins need minor changes in Picard and changes to the Picard website - and so it seems to me to make sense to use Jira for Plugin tickets too.

Often=>Sometimes.

Sophist-UK: yes

I was going to talk more on that later on my topic

( https://chatlogs.metabrainz.org/brainzbot/metab... is the discussion last week )

samj1912: I don't think we'll get to that topic today. :/

Ah :p

We have 3 minutes left.

Oh yes its almost time

I did add a third topic but can't remember what it was now. LOL

(Sorry, wrong link: https://chatlogs.metabrainz.org/brainzbot/metab... )

Sophist-UK: It's in /topic :)

Last week I said "I think picard-plugins should still live GH issues, since picard-plugins are not supported by "MetaBrainz", but are meant to be much more like a "hotpot"(?) for Picard users to submit their things to."

I still think so.

Yes - but I believe Picard-2 is moving in the direction of making some existing functionality a plugin.

It is slightly more supported than userscripts, but should not in any way be considered officially MetaBrainz supported.

Oh - Picard is Metabrainz supported? ;-)

Sophist-UK: And that is fine.

Sophist-UK: Yes.

Oh yes - my third proposal (if we have time)....

Freso: Still, we relied on it before updating MB style guidelines.

Sophist-UK: We don't. :/

Didn't think so...

about?

zas: picard-plugins issues on GH or in Jira...

until we have "official" plugins i prefer GH

+1

agreed

Let's stick to GH then, until Picard 2.0 is further along and maybe we can reevaluate later.

Ok.

Thanks for your time everyone!

</BANG>

Thanks. TTFN

Sorry reosarevok and Sophist-UK and samj1912 for not getting to your topics. :/

Making some plugins “official” is planned for Picard 2.0?

yvanzo: It's all up in the air right now, I think. Everything's possible. :)

yvanzo: the idea is still not clear

hmmm. has this been discussed and I've missed it?

Quesito: ?

There were previously semi-official plugins i.e. those included as standard when you install Picard.

Quesito: Not really, fully. I think.

Just vaguely been hinted at, maybe, kind of.

interesting

It is already the case I think - i.e. some cover art functuionality is implemented internally as plugins.

It might make sense e.g. to let users choose which cover art plugins to install rather than include them all - or it might not.

Sophist-UK: But they're not plugins. :)

Not now.

Sophist-UK: Sure, and that's one of the things samj1912 is planning for 2.0.