~dmbaturin/soupault

2 2

Reclarification of the Git mirror status + Nix

Details
Message ID
<4Gp7WV4y0Bz9rxg@submission02.posteo.de>
DKIM signature
pass
Download raw message
Some time has past since I last mentioned it. I’m at the point where I want to support that Nix derivation upstream in `nixpkgs`; I recently tried and got the build working in a local Flake, so with a little adjustment, I could add and be the maintainer. As such I have a few questions:

1. Although previously decided, do we want still want the Nix derivation to _not_ be in the `soupault` repo and instead only be in upstream Nix. The advantage of in this repo is that it become easier to subscribe to this repo and get updates faster than approval through Nix. The obvious downside is maintainence here which is unrelated would give dmbaturin possible extra work and merge requests to manage in something they (sorry, I didn’t see your pronouns listed at glance on any social media or in the “about” blog section) are not very familar with. An alternative could be creating an ‘org’ and having `nixpkg` repo, but that doesn’t seem useful and may conflict with #2. I will assume nothing Nix in this project unless stated otherwise (just reopening for the time).

2. Also discussed previously, but I want to be clear for Nix: what is the canonical repository? The Soupault website says GitHub and Codeberg are both ‘official’, but a) for Nix, I believe I have to pick just one and b) as of the `3.1.0` tag, I do not see anything pushed to Codeberg. Previous discussions mentioned trying to make it easy to mirror; this could be automated on GitLab through the settings (dmbaturin has an account but Soupault doesn’t exist here and GitLab while open, it has some issues with being beholden to VC investors). Codeberg has a blog post about using `git push --mirror` but that is to say either GitHub or Codeberg needs to be the origin/primary/canonical ‘mirror’ and the other is not. Sourcehut _has_ a Soupault repo, but is very outdated. Does dmbaturin want to just use GitHub as canonical? I personally I’m doing my best to support all projects stepping away from Microsoft’s GitHub for the reasons that probably prompted the project to support multiple repos, but it seems to have created a burden over time.

3. Is the Soupault Atom feed the best, agnostic way to see when there will be new version releases?

Thanks again for the tool and answering questions. The answers will inform me on how to get this project packaged for easy consumption.
Details
Message ID
<dc0d37b2-055d-ccb1-c548-1cad84b3848b@baturin.org>
In-Reply-To
<4Gp7WV4y0Bz9rxg@submission02.posteo.de> (view parent)
DKIM signature
pass
Download raw message
Hi toastal,

>do we want still want the Nix derivation to _not_ be in the `soupault`
repo and instead only be in upstream Nix

I think I'd prefer it to be in the upstream Nix, because I indeed lack
skills to update and fix it if needed. If it's in the upstream repo, it
will be looked after by people who have far more Nix experience than I do.

>I didn’t see your pronouns listed at glance on any social media or in
the “about” blog section

Dani[ie]l is a common male name of Jewish/biblical origin in many
countries. I always assumed it's so common that specifying pronouns
separately would be redundant. In any case, I use male pronouns (though
"they" is fine too).

>Also discussed previously, but I want to be clear for Nix: what is the
canonical repository?

I hate to say that, but I think the GitHub one is going to stay the
canonical one for a while.

Soupault is a very niche project so far. You have to be incredibly big
to move away from GitHub and have the contributors follow, and soupault
is anything but. The entire OCaml ecosystem is on GitHub, likely for
that very reason—it's a niche language after all and can't create its
own network effect.
The main reason I neglected the alternative repos is that they never see
any activity, while the GitHub repo sees at least _some_ activity (well,
not counting you—but you are the only one).
If you are small, you need all network effect you can get, else you will
get nothing.
In fact, I earlier I gave up and move another, _much_ bigger project
_to_ GitHub and that was the point when it went from no contributions
from anyone to a modest but steady flow of patches. I'm not happy with
it, but I also have no illusions about average person's willingness to
register an account to contribute (my data mining shows that of people
who contributed to that bigger project on GitHub, no one registered
shortly before contributing—in fact most accounts are old and only very
occasionally active).

I'm holding my breath for the federated Gitea effort. That can make a
real change, and I hope it will.

That said, I'm not happy about out-of-sync mirrors either, it's just
that maintaining them is a chore, and it's easy to forget to push to
every remote (I've pushed the 3.1.0 to codeberg now). I'd like to
automate keeping them in sync, just not yet sure what would be the best
tool to do that.
If you have any suggestions, please share!

>Is the Soupault Atom feed the best, agnostic way to see when there will
be new version releases?

I publish a blog post for every release and I don't plan to stop, so I
think it is.
I'm planning to also add JSONFeed as a more easily machine-readable
alternative, and maybe add custom machine-readable fields to it, since
it explicitly supports extensions.

On 8/16/21 4:04 PM, toastal wrote:
> Some time has past since I last mentioned it. I’m at the point where I want to support that Nix derivation upstream in `nixpkgs`; I recently tried and got the build working in a local Flake, so with a little adjustment, I could add and be the maintainer. As such I have a few questions:
>
> 1. Although previously decided, do we want still want the Nix derivation to _not_ be in the `soupault` repo and instead only be in upstream Nix. The advantage of in this repo is that it become easier to subscribe to this repo and get updates faster than approval through Nix. The obvious downside is maintainence here which is unrelated would give dmbaturin possible extra work and merge requests to manage in something they (sorry, I didn’t see your pronouns listed at glance on any social media or in the “about” blog section) are not very familar with. An alternative could be creating an ‘org’ and having `nixpkg` repo, but that doesn’t seem useful and may conflict with #2. I will assume nothing Nix in this project unless stated otherwise (just reopening for the time).
>
> 2. Also discussed previously, but I want to be clear for Nix: what is the canonical repository? The Soupault website says GitHub and Codeberg are both ‘official’, but a) for Nix, I believe I have to pick just one and b) as of the `3.1.0` tag, I do not see anything pushed to Codeberg. Previous discussions mentioned trying to make it easy to mirror; this could be automated on GitLab through the settings (dmbaturin has an account but Soupault doesn’t exist here and GitLab while open, it has some issues with being beholden to VC investors). Codeberg has a blog post about using `git push --mirror` but that is to say either GitHub or Codeberg needs to be the origin/primary/canonical ‘mirror’ and the other is not. Sourcehut _has_ a Soupault repo, but is very outdated. Does dmbaturin want to just use GitHub as canonical? I personally I’m doing my best to support all projects stepping away from Microsoft’s GitHub for the reasons that probably prompted the project to support multiple repos, but it seems to have created a burden over time.
>
> 3. Is the Soupault Atom feed the best, agnostic way to see when there will be new version releases?
>
> Thanks again for the tool and answering questions. The answers will inform me on how to get this project packaged for easy consumption.
Details
Message ID
<4Gp8th2N24z6tmR@submission01.posteo.de>
In-Reply-To
<dc0d37b2-055d-ccb1-c548-1cad84b3848b@baturin.org> (view parent)
DKIM signature
pass
Download raw message
> I think I'd prefer it to be in the upstream Nix

Roger.

> GitHub

Sucks, but it’s not like I don’t understand. Nixpkgs is all done through GitHub. There’s been some attempts to *try* to get an alternative mailing list route going, but it kinda fizzled. Elm has tied all package management *AND* identity to GitHub. PureScript supports alternatives in theory, but no one seems to have a major package publish outside GitHub (this I hope to change this :fingers-crossed:, but I need to create something people _really_ want and I will sadly probably be responsible for fleshing out any current building issues). 

I feel like the it’s too difficult to do both. Buying in to the non-mailing-list route ends you in a GitHub clone situation like GitLab, Gitea, Codeberg, versus mailing-list-only Sourcehut, default repo. Most people are now accustomed (myself included, in hindsight regrettably, but a GUI *was* easier to learn when I was first picking up Git). I think because most people learned through GitHub back in its independenc and ‘cool’ phase, will default to “issues” and “pull requests”. A lot of projects have had some success on GitLab and a lot of the FOSS (like GPL FOSS) community _has_ moved (to gitlab.com or self-hosted) because of GitHub’s close-source, tracking-on existence and still get contributors used to that style and share philosphical views, but GitLab does certainly have its issues (as noted, beholden to VC investors that may turn when they want). At that point, it’s a political stance that is more personal than likely not affect change unless your project is too big and too important to fail (e.g. Linux kernel). I’m personally moving all of my stuff to GitLab and Sourcehut, but I’m also fond of the Haskell motto: avoid success at all costs ^_^

Commiserating rant aside, I know where your heart and head lie in looking for success and adoption. Cannot say I blame you, *but* you may want to update your website docs if this is the case.

* * *

Okay, well then I’ll work on a Nix derivation pointing to GitHub for the time being. Thanks again for the quick response.
Reply to thread Export thread (mbox)