jdev - 2025-02-12

this is only vaguely relevant, but uh, have you heard of federated maintainership?

No what is it

Is that a fancy word for having multiple maintainers 😁

are you familiar with the concept of open federation?

it's basically that, but for git repos. we deprecate the concept of "upstream" and require every git clone to be fully qualified, and use an interface that shows all repos as having more or less equal weight

anyone can become a maintainer by setting up an instance and putting their repo in it. every other instance will then list their repo alongside yours.

(and also, who are we kidding, this is xmpp, ofc you're familiar with open federation :p but anyway)

isnt that just cooperative forking?

we don't know if it has an existing name. we've been calling it federated maintainership since a few days ago or so.

(tho the idea is much older, we came up with it around the time mastodon's BDFL model was still an issue)

we can't seem to find anything about cooperative forking

here's where we called it federated maintainership: https://github.com/tukaani-project/xz/issues/163

Soni: isn't that just... git used how and for what it was created for ?

moparisthebest: (this is not meant to be combative) okay but, was it? we mean, even the kernel isn't open federation: there's a single upstream - linus' tree, and then there's a bunch of authorized maintainers, and they all use the same git host. no?

(linus's? something like that)

(and we think linux maintainers are a little elitist but we digress)

They don't use a host at all really, just email (federated!) patches to a mailing list

no we're pretty sure linus pulls from other maintainers every now and then, it's not all email

I don't see how you could have a project where anyone who wanted to could push code to a place distros would pull it?

we think they're called "octopus merges"

just because one tree chooses to issue releases doesn’t meant the other trees aren’t real

(sometimes spanning like 60 trees or something)

that’s really all “being an upstream” is is someone willing to issue a release and give it a name

Right individuals can host their git repos publicly in which case it's a full and complete copy and distros or whoever could use that instead

In fact that's pretty common, for example linux-zen and linux-hardened in Arch Linux have a different upstream that is not kernel.org or Linus

moparisthebest: okay, but those are seen as "soft forks", not federated maintainers

Debian once used my fork to base xmpp-irssi package on and I didn’t even have releases

singpolyma: yeah, and you wouldn't even know about it until they told you?

and tried to upstream their patches and stuff

Soni: so in your model no one ever makes a release?

singpolyma: well, distros make packages. and that's the closest you'll get to a release

How do they decide who's copy to package?

point being, why shouldn't you use debian as the upstream for your fork?

And then like, what if Debian and redhat make different incompatible decisions?

they fork from you, you fork again from them, and it all explodes

(okay it doesn't explode, but like... they're making patches, right? why shouldn't they have a stake on it?)

moparisthebest: see also the github issue we linked, it (very) briefly discusses that issue

right but this is all how it works now, except for banning anyone to make a release or have a version number

you do still have a version number: the git commit

……but why ?

that’s not a number

Soni, the issue with the model (as I understand it) is that in the end decisions must be made, and trust must exist. That can hinge on a single person, or many, but in the end you need a way to make decisions and communicate

a 160-bit number is still a number

mathieui: but it doesn't need to be middlemanned by an upstream, it can be ad-hoc

mathieui: well, do you?

like Debian has to decide what to package but that’s up to the DM no one in the project *needs* to be involved

mastodon would benefit from it because everyone wants something different from the software but more importantly *nobody gets anything from the software*

(well, maybe that's gonna change now that mastodon is no longer BDFL-based, but still)

I’m not saying I want to totally ban releases, but I’ve done it for some stuff before and it can work I think

this is the problem it solves: different ppl have different expectations

(and we should embrace that instead of... steamrolling ppl's needs we guess?)

well you can still operate this way even if one person calls themself maintainer and makes releases. Just ignore them

this would make more sense with a patch-oriented vcs

I'm wondering how this general software maintenance philosophy discussion is on-topic for here?

busted

singpolyma, I mean, you don’t have to do releases, but you kind of need to have some level of cooperation between multiple actors if you don’t want things to be a pile of crap to maintain because patches don’t magically apply regardless of the history

jonas’: you’re right, it’s not. Sorry

well, we come here to wonder if any xmpp *devs* would be willing to try it for xmpp :p

also yeah, that’s not really XMPP development

Soni: xmpp:dev@chat.moparisthe.best?join

(it'd be cool to try it for the protocol itself but, eh oh well)

(that's probably too hot of a take for this place)

> Soni: xmpp:dev@chat.moparisthe.best?join that's a muc link, you can carry on there ↺

We can kinda see what happens in practice when distro maintainers (who are responsible for *a lot* of packages, and not experts in any one) make major decisions that contradict upstream (who *are* the experts for that project) That's how we got the fatal Debian key generation bug of 2008 that still haunts us https://16years.secvuln.info/ (Debian maintainer thought he knew better and broke everything) *and* it's what enabled the xz thing to be a problem (Debian and redhat maintainers thought they knew better and patched all these vulns into openssh)

qy: what should we call that room? (we need to give rooms names, because bitlbee)

"Dev chat"

what kind of dev chat

Just general dev chat, so this would be ontopic there

thanks everyone for moving the discussion elsewhere :)

> thanks everyone for moving the discussion elsewhere :) 👍 ↺

> thanks everyone for moving the discussion elsewhere :) 👍 ↺