XSF Discussion - 2021-01-10

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

It’s still based on the DOAP data.

Shiny

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

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

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

:+1:

Any ideas on how to get compliance badges in there?

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

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

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

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

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

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

We probably should get rid of the Other category.

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

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

Well that didn't take long

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

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

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

it shouldn’t work like that

It shouldn’t, but does it?

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

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.

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

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

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)

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.

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

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

oh cool, thanks. I agree with Guus.

I thought there was more discussion. 🤔

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

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"?

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

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.

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

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

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.

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

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

That would make more sense to me

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

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

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

Thanks!

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

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.

Generate a CSV file and call it a day.

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