XSF Editor Team - 2017-09-27

if anyone could revert what peter did ... ;-)

Peter didn't say what he did, so I can't revert it easily.

I was afraid so

at least everyone now learns how much spam an open ML attracts :)

It's much less bad than I expected, this wasn't a particularly bad day, it seems.

It's the days where it gets multiple thousand in one day that are a real nuisance.

sounds great

Oh. It looks like as well as the change letting spam through, it's also now got a moderation list that needs handling.

I guess that means we need to get Sam onto the admin list for the list so he can handle the moderation queue. And hopefully fix whatever configuration is letting the spam through without it hitting the queue.

Kev, there’s a seperate moderator list (if you care about the privilegues)

right below the list of admin addresses

Ta.

The spam is pissing me off significantly already.

understandable

Especially as we had a solution to this problem.

yeah, I‘m surprised peter made that change and then disappeared :/

Can't blame people for doing what they're asked.

it could’ve used a bit more testing

on the upside, that’s a whole new type of spam to train my filters on

For what it's worth I still don't think we shouldn't go back to the "silently drop messages" strategy, but I guess I just have a well trained spam filter because most of them were caught for now. I would still like the list to just be configured how every other list we have is, maybe sync the standards/members lists to a whitelist for receiving.

We can't be configured how every other list is, because we want to be able to accept XEP submissions.

If we could be configured how other lists are (only editors can post), it'd be easy.

We can't accept XEPs via email when they get lost in the void silently or get lost in a ton of spam. It's consistently a problem that people can't figure out why their messages aren't getting to editor@, and apparently spam is a problem for some people, and I think we've gotten one XEP by email since I've been doing this so why not disable it?

If people want to submit an XEP by email they can send it to one of us directly, it will be no less documented or hard to do than the current state of affairs.

https://hub.docker.com/r/xmppxsf/xeps/builds/bj8obtizkjjqexc6dzqm2ht/ okay, these build failures due to some XSLs not loading from sourceforge are getting annoying

*sigh* indeed

Loading random libraries from sourceforge as part of a build would be concerning even if it wasn't breaking, but I don't know how XSLT works enough to know if we can do it locally or remove the dependency somehow.

I'm on a two-week intensive coding thing with work at the moment, come Monday I'll hopefully have a few cycles to spare if you remind me then.

Not that I suggest I'll be competent to solve anything.

Kev: Thanks; if you know anything at all about XSLT or XML you're more competent than me

I know both, but I’m afraid this might be more or less deeply in texml

I suspect we all know a little about XML.

XSLT is way outside my comfort zone.

I kinda like it.

I built a whole CMS around it, kindof.

I know that there are things that look like <this> and other things that look like </this> (or sometimes like <this/> for some reason) and that they sometimes have key-value pairs on them and text in the middle.

Oh, and sometimes things start with xml: and those get inherited to all the other things under the top level things.

jonasw, we can certainly put http://xsltsl.sourceforge.net/modules/stdlib.xsl in our repo and load that instead

and we’ll have to adapt paths in there too

in our xsl, yes

doesn’t the stdlib in turn reference other .xsl files?

ah..right

that’s what put me off from simply fixing this

but sure, we should do it.

I am not proud of knowing so little about a core part of the technology we develop, but it also makes me want to cry so I've never bothered to learn more than enough to get by :(

ugh

I can’t even load it right now.

can you download the XSL files right now?

there seems to be an issue there

nope

great

let’s hope they come back

https://github.com/oarevalo/WebReports/tree/master/common/xsltsl-1.2.1

smart

If I have time after dinner (after board meeting), I might give it a shot at fixing this

just a heads up so that we don’t duplicate work

ok

editors: I've just tweaked the website configuration. images are now no longer served from a static file directory on EOS, but from the xmpp.org docker instance instead.

If this breaks anything, blame me (and let me know)

Thanks Guus!

don't thank me yet

I think this was in place for a reason...

I just don't know what that was :)

… for letting us know that you're trying to break things.

:)

s/trying/going/