At the end I think there will be just a few "active" enough to move to my server, but when I have the infrastructure, any new repo will go there quite naturally.

Show thread

56 repos now, and a number of them are archived (just because it might be nice to have that there for historical reasons).

It is mildly entertaining that Copilot may get anything from there 😂

Show thread

@kensanata Yes, I want to like it too. I didn't even try to get contacts to use it; tried with two accounts and it was pretty slow to deliver the messages (actually: OK for SMTP, slow for instant messaging).

@kensanata Delta messenger? The email client? How do you feel about it?

@pulkomandy I use git tags for releases; but in this case there's no releases. I used the repo as a simple way to share that code, and it is pretty much "use master"

Some are like one tool. I could consolidate, for example, all C64 tools together in the same repo. I don't do "releases" on those anyway.

Show thread

I'm almost decided to move to self-host my git repos. I have 72 in GH, 3 in GitLab, and I'm sure some in Bitbucket (private).

So yep, may need some automation. Although I should move the ones that are important first, and then decide what do I do with old ones that I don't care (like stuff from 2010).

Started to read the Hobbit with Vic. 30 something pages so far, and he seems interested.

@Sandra @algernon if I may chip in, that post makes sense for a different set of requirements. I'm keen on self-host, but I won't self-host a forge for my personal projects. It doesn't make sense.

If at some point any of them is successful enough for my minimal workflow to be an issue, I can migrate to a hosted forge that aligns with my principles.

(you don't necessarily need register to write on a wiki, and subscribing to a mailing list is very different from having account in a forge 😅)

@algernon @kensanata @Sandra you could say the same about registering in any hosted service. If it is down to "everybody has GH", we are missing the point.

Being on GH I get almost 0 contributions anyway. Missing yours doesn't change anything.

@kensanata @Sandra I prefer email. My email client is always on, I have folders, filters, etc, I even implemented GTD once. If you want to contribute, you need email.

GH is sending me emails. I just need GH out of the picture, but the public bug tracker is useful (avoid duplicate reports, other users contribute fixes, etc). That's what I like in your wiki solution.

I need to think about it. Could it be a public inbox the answer? Don't know yet.

Juan boosted

I think contemporary development culture has a CI-fetishization problem and this should be talked about a lot more.

I don't know if this is an unpopular opinion or just not interesting to a lot of people (at least I don't see it pop up much in my feeds for whatever reasons), but the rising amount of commit-triggered senseless cloud computation I see in recent years is really worrisome to me. I can appreciate the utility of a thoughtful automated process that thoroughly checks an entire release before it rolls out on big critical infrastructure, but what I see around me is so often overblown pseudo-testing that provisions entire serverfarms to crunch numbers for half an hour everytime any dev at an org commits as a much as a fix for a typo on some random work-in-progress branch. In the face of our existential climate emergency I can only consider this practice completely mindless, and complete madness. We can not keep doing this.


In reality, you don't even need that:

$ git archive --format=zip --remote=https://myhost.virtual/repos/myoproject.git master

I still think having a web view to list branches etc, is convenient. But you are right: is not essential.



Oh, I got you now. Exactly as binary releases, yes. Convenience. You can checkout an archive of master, or any branch on the repo etc.

But yes, it is just a web based git client.


@Sandra @kensanata Sometimes you just want the project ("the code") and not interact with git at all. I those cases, you get whatever tagged version as an archive and git is out of the picture (without the repo history, that is not there).

@kensanata @Sandra the only thing I don't like about the email workflow is not having a public view of a "bug tracker", which you wiki approach solves nicely. I need to think a bit about this, I don't want to give up on a pure email approach.

@kensanata Your approach of wiki for issues + cgit is very smart; I moved my new/active bits to gitlab, but perhaps I should do self-hosting moving to email workflows.


@kensanata @Sandra I find it useful to browse the code, it is convenient.

cgit also gives you a way of download archives based on tags, isn't it? Which can be useful to provide "releases" as source code (via "refs"). @kensanata you don't have that enabled; see for example:

Show older
Mastodon @ SDF

"I appreciate SDF but it's a general-purpose server and the name doesn't make it obvious that it's about art." - Eugen Rochko