XSF Editor Team - 2017-09-27

  1. jonasw

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

  2. Kev

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

  3. jonasw

    I was afraid so

  4. jonasw

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

  5. Kev

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

  6. Kev

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

  7. jonasw

    sounds great

  8. Kev

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

  9. Kev

    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.

  10. jonasw

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

  11. jonasw

    right below the list of admin addresses

  12. Kev


  13. Kev

    The spam is pissing me off significantly already.

  14. jonasw


  15. Kev

    Especially as we had a solution to this problem.

  16. jonasw

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

  17. Kev

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

  18. jonasw

    it could’ve used a bit more testing

  19. jonasw

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

  20. SamWhited

    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.

  21. Kev

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

  22. Kev

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

  23. SamWhited

    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?

  24. SamWhited

    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.

  25. jonasw

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

  26. SamWhited

    *sigh* indeed

  27. SamWhited

    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.

  28. Kev

    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.

  29. Kev

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

  30. SamWhited

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

  31. jonasw

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

  32. Kev

    I suspect we all know a little about XML.

  33. Kev

    XSLT is way outside my comfort zone.

  34. jonasw

    I kinda like it.

  35. jonasw

    I built a whole CMS around it, kindof.

  36. SamWhited

    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.

  37. SamWhited

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

  38. Tobi

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

  39. jonasw

    and we’ll have to adapt paths in there too

  40. Tobi

    in our xsl, yes

  41. jonasw

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

  42. Tobi


  43. jonasw

    that’s what put me off from simply fixing this

  44. jonasw

    but sure, we should do it.

  45. SamWhited

    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 :(

  46. jonasw


  47. jonasw

    I can’t even load it right now.

  48. jonasw

    can you download the XSL files right now?

  49. jonasw

    there seems to be an issue there

  50. Tobi


  51. jonasw


  52. jonasw

    let’s hope they come back

  53. Tobi


  54. jonasw


  55. jonasw

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

  56. jonasw

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

  57. Tobi


  58. Guus

    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.

  59. Guus

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

  60. SamWhited

    Thanks Guus!

  61. Guus

    don't thank me yet

  62. Guus

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

  63. Guus

    I just don't know what that was :)

  64. SamWhited

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

  65. Guus


  66. SamWhited