XSF Discussion - 2021-01-10


  1. Link Mauve

    Hi, I did a thing: https://linkmauve.fr/software/clients.html

  2. Link Mauve

    It’s still based on the DOAP data.

  3. Zash

    Shiny

  4. Link Mauve

    Still not using Pelican, because I still haven’t been able to build it.

  5. Link Mauve

    I’d like to merge it quickly, but I’ll need help with integration.

  6. Link Mauve

    I was thinking about extending it with JS to let the user pick the platform(s) they’re interested in.

  7. Zash

    :+1:

  8. Zash

    Any ideas on how to get compliance badges in there?

  9. Link Mauve

    I already have access to the data in the generator, so it should be a matter of finding the right formula.

  10. Zash

    I have a thing written in Lua that can do the comparison, not sure where to go from there

  11. Link Mauve

    I can probably translate it into Rust if you give me the code.

  12. Zash

    Link Mauve, https://code.zash.se/compliancer/file/tip/compliance.lua

  13. Link Mauve

    Zash, now with toggleable section, guessed from the User-Agent.

  14. Link Mauve

    Only when JS is supported, otherwise they’re all extended.

  15. Link Mauve

    We probably should get rid of the Other category.

  16. Link Mauve

    Alright, now I’d just like to get the compliance badges, and the thing should be good to go!

  17. Link Mauve

    Uh, pull requests to https://github.com/xsf/xeps are now failing with: anyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

  18. MattJ

    Well that didn't take long

  19. mathieui

    " Anonymous and Free Docker Hub users are limited to 100 and 200 container image pull requests per six hours. "

  20. mathieui

    is there that much activity on the XSF repo? :o

  21. Link Mauve

    Maybe people use our free pulls through the fork mechanism or something like that?

  22. mathieui

    it shouldn’t work like that

  23. Link Mauve

    It shouldn’t, but does it?

  24. MattJ

    If per IP then we're sharing with other Github users (or whatever CI we are using these days)

  25. SamWhited

    Stupid question, but can we remove the link to txxmpp, whatever that is? Having a link to a C source file doesn't actually inspire any confidence that XMPP clients are easy to use and just doesn't make a lot of sense in my mind.

  26. SamWhited

    (on /software/clients.html, I mean)

  27. mdosch

    I think there was a discussion about it. Maybe in an issue or the mr itself.

  28. mathieui

    arguably it could be considered not a "full-fledged" XMPP client, and as such I’m not sure where to put it (considering the XSF is trying very hard to *not* make editorial decisions on such topics)

  29. SamWhited

    I dunno, seems perfectly fine to make an editorial decision when there's no website, no information, and it's not clear ot me what it even is.

  30. mdosch

    https://trello.com/c/GHGXcYuq/405-how-should-we-approach-txxmpps-pr

  31. mdosch

    https://github.com/xsf/xmpp.org/pull/612

  32. SamWhited

    oh cool, thanks. I agree with Guus.

  33. mdosch

    I thought there was more discussion. 🤔

  34. SamWhited

    Having a link to a random C file on the website with no context or information just makes us look bad.

  35. mathieui

    Maybe a requirement could be added to the pull requests "the project MUST at least have a web page we can link to that describes it and what it does"?

  36. SamWhited

    That sounds like a good start to me. I'd also say "and be a client usable out of the box without building anything" personally

  37. mdosch

    Weird requirement. Once a distri adds txxmpp to it's repo it's fullfilled while it's still a niche tool most regular users won't need.

  38. Link Mauve

    That would exclude most Linux software, which are generally distributed by third parties and not by the project itself.

  39. SamWhited

    Yah, it's not comprehensive, I'd absolutely be for adding more strict requirements.

  40. SamWhited

    I mean, don't interprete it so literally, yes, random clients that aren't distributed by a first party but are in all the distros repos are obviously widely distributed and easy to get.

  41. SamWhited

    But fine, somebody else can equivocate about what the perfect wording for the rule is, I'm just concerned that a single C source file is definitely beyond what should be linked on the website and as usual makes us look completely unable to make a user friendly chat experience

  42. mathieui

    alternatively, replace "Libraries" with "Libraries/Tools" and put things like txxmpp in there

  43. SamWhited

    That would make more sense to me

  44. mathieui

    (but even then I believe a page describing it would be a nice requirement)

  45. mdosch

    > alternatively, replace "Libraries" with "Libraries/Tools" and put things like txxmpp in there +1

  46. SamWhited

    Issue made for further opinions / discussion: https://github.com/xsf/xmpp.org/issues/866

  47. Link Mauve

    Thanks!

  48. Link Mauve

    SamWhited, I just submitted a XEP, hopefully addressing your comments from our discussion the other day. :) https://github.com/xsf/xeps/pull/1027

  49. SamWhited

    Thanks; it will be nice to at least have a reference. I still think we're over engineering it for no reason though. I tried again to have my static site generator spit out a file (I realized I actually do know what XEPs are implemented because of that, so I can probably actually generate the whole thing), but it doesn't support namespace prefixes so it was a no go either way.

  50. Zash

    Generate a CSV file and call it a day.

  51. Zash

    Something something `csv2 < doap.csv | sed | 2xml`