talk me beautifull
category: general [glöplog]
With certain regularity, folks post non-fixes on the "fix me beautifull" thread. More often than not the topics raised in such posts are not irrelevant or undeserving of a reply, but just clearly in the wrong place as they do not contain directly implementable fixes to prods, which is the raison d'être of the "fix me beautifull" thread.
Recently, a number of Pouët staff members gathered, and one of the conclusions of the conversation they had was that a new thread for post such as described above made sense. It was also decided that "talk me beautifull" would be a fitting name for this thread. Finally, porocyon just made a suitable first post for this thread, which I'll copy below in it's entirety to kick off this thread. Looking forward to what future contributions/questions that are in a similarly reasonable vein the userbase will come up with!
Now back to porocyon's question:
Recently, a number of Pouët staff members gathered, and one of the conclusions of the conversation they had was that a new thread for post such as described above made sense. It was also decided that "talk me beautifull" would be a fitting name for this thread. Finally, porocyon just made a suitable first post for this thread, which I'll copy below in it's entirety to kick off this thread. Looking forward to what future contributions/questions that are in a similarly reasonable vein the userbase will come up with!
Now back to porocyon's question:
Quote:
I wanted to add a link to the source repository of my revision release.
Initially, I labelled it "source", which got rejected as per the FAQ because it's not a direct download link. Fair enough, so I again submitted a request to add the link, now with label "codeberg". This again got rejected, with only a link to the same FAQ entry as explanation.
Now, the FAQ states:
Quote:
Sources:
source (direct link to file only)
github
googlecode
[...]
The above list is by no means complete, it's only supposed to give you some pointers.
Keep in mind that we are going for a minimalistic approach, please consider whether the link you're trying to add is of any interest to others !
I had hoped, by this wording, that there would be other git repo hosting sides allowed besides Github (now infamous for its bad uptime) and Google Code (which has stopped existing over a decade ago). Several emudev people have been digging into the source code already (as I haven't written the writeup yet), so I would also argue it is, in fact, "of interest to others".
So what exactly is the grounds for refusal here?
porocyon: grounds for refusal at this point in time is the lack of traction any particular repository site besides github has achieved thus far. codeberg has been suggested maybe a handful of times so far, that's not enough to warrant being included in the list of labels recommended in that FAQ article (#45) you mentioned.
this could obviously change if codeberg or another github alternative becomes sufficiently popular to convince us to add it to the FAQ article, but that does not appear to be likely to happen very soon.
what would be allowed is posting a direct link to a zipped archive of the sources on a repository site, because as long as it can be linked to directly it can be on any site you wish. i'm not sure if codeberg allows direct linking of files but i'm sure you do(?).
to effectively argue for inclusion of codeberg as label in the FAQ, i would suggest to use the same vehicle that we've suggested for platform suggestions, which would be to create a list on this site to document which prods can be found on codeberg. this would make it obvious what the potential of the site in our context is, and would also help to add links if and when it is decided that codeberg has reached the required threshold.
i hope that answers your question :)
this could obviously change if codeberg or another github alternative becomes sufficiently popular to convince us to add it to the FAQ article, but that does not appear to be likely to happen very soon.
what would be allowed is posting a direct link to a zipped archive of the sources on a repository site, because as long as it can be linked to directly it can be on any site you wish. i'm not sure if codeberg allows direct linking of files but i'm sure you do(?).
to effectively argue for inclusion of codeberg as label in the FAQ, i would suggest to use the same vehicle that we've suggested for platform suggestions, which would be to create a list on this site to document which prods can be found on codeberg. this would make it obvious what the potential of the site in our context is, and would also help to add links if and when it is decided that codeberg has reached the required threshold.
i hope that answers your question :)
Thanks for answering. (Also, hooray, my foolishness now gets enshrined in the opening post of a BBS topic :D )
This strikes me as slightly odd, because International Shipping has a Bitbucket link, and vondehi has a link to a gitlab (not -hub) repository... marked as "source". Ok, the label of the latter should probably be changed then, but removing it feels pretty harsh for a demotool especially, because access to the repository is sort of a prerequisite.
I'm not sure if this is a good idea? With prods, not having a platform category doesn't stop people from making prods for those platforms. But for source code repos it'd basically motivate people more to stay at github.
In any case, I've created a git tag, which makes the source repo website generate a .zip download for the repo. I've then added a request to add that link as the "source" download thingy.
Quote:
lack of traction any particular repository site besides github has achieved thus far
This strikes me as slightly odd, because International Shipping has a Bitbucket link, and vondehi has a link to a gitlab (not -hub) repository... marked as "source". Ok, the label of the latter should probably be changed then, but removing it feels pretty harsh for a demotool especially, because access to the repository is sort of a prerequisite.
Quote:
i would suggest to use the same vehicle that we've suggested for platform suggestions
I'm not sure if this is a good idea? With prods, not having a platform category doesn't stop people from making prods for those platforms. But for source code repos it'd basically motivate people more to stay at github.
In any case, I've created a git tag, which makes the source repo website generate a .zip download for the repo. I've then added a request to add that link as the "source" download thingy.
Quote:
This strikes me as slightly odd
All i can say is, sometimes mistakes are made, or issues can be overlooked. We've been rooting out (links under) non-standardized labels for years, these obviously slipped through the cracks. regardless of why and how, we'll keep on aiming at uniformity across the database for links that are part of the prod data.
Quote:
But for source code repos it'd basically motivate people more to stay at github.
Well, that's the point isn't it? LIkewise, if we'd add Codeberg, the hope would be that it'd motivate people to use that platform to share sources.
Quote:
In any case, I've created a git tag, which makes the source repo website generate a .zip download for the repo. I've then added a request to add that link as the "source" download thingy.
Thanks- approved (obviously)! Come to think of it, I sure hope other folks who have their prods on Codeberg would follow your example, as this will be just-as-if-not-more effective in keeping track of how many prods can be found there and as a function of that, how much sense it would make to standardize Codeberg at any given point in the future.
Could we have, like, “repository” or something instead of referring to specific providers? I mean, we have “download” not “scene.org” (I think maybe we used to have it), we have “soundtrack” not “untergrund”, so surely we wouldn't need to limit ourselves to GitHub if the point is to have fewer labels. TBH I'd be fine with collapsing “youtube”, “vimeo” and “video” into one, too, but I realize this is more controversial.
Quote:
Could we have, like, “repository” or something instead of referring to specific providers?
Having assessed suggestions for these kind of links for nearly 20 years now, I'm not convinced that such a step wouldn't lead to a considerably more fragmented landscape of repository platforms we'd be linking to. Or to follow the video analogy, collapsing all video labels into one would probably lead to a whole bunch of oddball video platforms being suggested (Peertube, DailyMotion, Twitch, and so on and so forth).
... and why is that bad? Most "minisite" links are all on unique domains, after all.
Quote:
... and why is that bad? Most "minisite" links are all on unique domains, after all.
And tons and tons and tons of download links! And source. And video. And soundtrack.
It's not clear to me why Pouët wants to have links to as few different domains as possible, but perhaps there's some deeper thought here? (I understand that “video” and “youtube” do have important functional differences around e.g. easy download vs. easy seeking, but I struggle more with finding the important differences between GitHub, Gitlab and Codeberg.)
Why would standardization be bad?
The standards exist, they're RFCs 3986 and 1945, together with git's repository archive format. Running "git clone" on all those source code repository URLs (whether Github, Gitlab, Bitbucket or Codeberg) just works. "Standardization" on which website hosts these feels much less consequential or consistent.
Because there are various use cases and a lot of different vendors of code hosting services. I think something like "code" or "source" or "repository" would be just fine. If I wanr to see the source, it doesn't matter to me where it comes from and people self-hosting zips is kind of outdated and less reliable than a link to whatever service.
... and indeed git clone works with everything if I want to clone it.
Quote:
Why would standardization be bad?
One could just as well ask, why should we be discussing on Pouët's BBS instead of standardizing on a Facebook group? I believe there's a fair bit of people around here that feel that supporting oligopolization is bad, and being forced towards it even worse. (And a whole lot of people who don't care.)
Quote:
people self-hosting zips is kind of outdated and less reliable than a link to whatever service
my perspective is different, when repositories are removed from the platform that hosts them we have no option but to delete the link, whereas if a source zip is removed we can in most cases replace it with a file from the automatic backup
That's a fair point as well. But why not both?
Fwiw, when I peek at sources out of curiosity, zips are extremely inconvenient. You need to download and extract them, which is painful on a mobile device. And if I want to compile something, git clone is the way to go.
Fwiw, when I peek at sources out of curiosity, zips are extremely inconvenient. You need to download and extract them, which is painful on a mobile device. And if I want to compile something, git clone is the way to go.
Well we currently do support both, and it's definitely not my intention to stop supporting either. But I am looking at these kinds of issues from a preservation/longevity perspective, hence my reluctance to add support for more platforms that cannot be easily (automatically) backed up.
the thing is, git repositories *do* allow for automated backups
Quote:
hence my reluctance to add support for more platforms that cannot be easily (automatically) backed up
To be clear, does this mean that you think allowing GitHub links in the first place was a mistake?
No
OK. Just so it's clear, my backup tool (which I presume is the only backup tool running on Pouët, correct me if I'm wrong?) does not back up git repositories, including GitHub repositories. GitHub pages are like any other web pages; the HTML is downloaded and saved, no dependencies.
Speaking of downloads; should Pouët allow download links that are ftp://? No browsers support such links anymore, AFAIK (except that they can possibly ask other programs to handle them on their behalf).
There is a similar problem in that Pouët now seemingly is force-HTTPS, which breaks some csdb links in Chrome (since they have redirect-to-HTTP, not redirect-to-HTTPS). See e.g. this prod, where clicking the download link in Chrome does nothing except post this on the console (it still works in Firefox):
There is a similar problem in that Pouët now seemingly is force-HTTPS, which breaks some csdb links in Chrome (since they have redirect-to-HTTP, not redirect-to-HTTPS). See e.g. this prod, where clicking the download link in Chrome does nothing except post this on the console (it still works in Firefox):
Quote:
Mixed Content: The site at 'https://www.pouet.net/' was loaded over a secure connection, but the file at 'https://csdb.dk//storage/ucRZOXcUljgcGcBl.php/17804/Act%20Now.zip' was redirected through an insecure connection. This file should be served over HTTPS. See https://blog.chromium.org/2020/02/protecting-users-from-insecure.html for more details.
ftp:// links as main download have been all but rooted out completely, for other types of links there's probably a few more still in existance (although some folks are helping us to fix those <3). non-secure http links, such as that example, still work fine when using rightclick>save as, but that's not to say we're not looking to fix them eventually.
Quote:
ftp:// links as main download have been all but rooted out completely
Hm. There are 942 of them in the latest dump. 672 of them are to ftp.untergrund.net and can trivially be moved to https. 124 more are to scene.org, likewise. 87 to amigascne.org and 12 to gathering.org. Could we perhaps move those automatically? The rest we can have a look at manually at some point.
Quote:
non-secure http links, such as that example, still work fine when using rightclick>save as, but that's not to say we're not looking to fix them eventually.
Perhaps csdb links specifically could move http -> https, also automatically? Sounds like an easy fix for an admin.
Quote:
International Shipping has a Bitbucket link, and vondehi has a link to a gitlab (not -hub) repository
...both of which have now been removed and shunted to the respective comments sections, where they're less readily visible. It just feels petty and arbitrary.
Coders are gonna put their code on their forge of choice, and while I haven't made the jump yet myself I certainly understand people's inclination to use "not github" nowadays. Is the message from pouet staff here then "use github or you can't have your source repo linked up top"? Sure, we can share source zips from non-github code forges, but the commit history in a repo can lend valuable context to how a prod came together over time, which you won't find in a source zip.
What if instead of a demo that can be considered "finished", someone shares a demotool that's under continuous development on a non-github code forge? Should that be denied a link to the repo too?
And while we're playing rules lawyer with the FAQ, it also states:
Quote:
making of (direct link to file only)
A few of my earlier exegfx entries have "making of" links pointing at youtube. Should these be removed, losing useful context, or should they be renamed to "youtube (making of)" like the corresponding link on Brainworm already is?
Quote:
"use github or you can't have your source repo linked up top"
until a suitable alternative achieves enough traction to warrant being added to the list that's pretty much it yeah.
Quote:
making of (direct link to file only)
that's been on the short list of suggested changes for a while now