(Please send To/Cc me if you'd like to continue on this branch of conversation, I'm not subscribed to -devel, only digests.)
On Wed, 04 Sep 2024 06:42:33 +0200, Jonas Smegegaard wrote: > Quoting Blair Noctis (2024-09-04 04:33:10) (...) >> > PICCA Frederic-Emmanuel writes: >> > >> >> What about dog fooding ? >> >> >> >> for now we can setup a schroot and sbuild very easily and start to build a >> >> local repository in minutes. >> >> >> >> But when it comes to install gitlab and the CI system it is another story. >> >> So we rely on the central salsa instance. (...) >> >> I do not know if I am clear but I have the fear that this >> >> centralisation will make us forget that de-centralisation is sort of >> >> "central" to the Debian way. (...) >> > I suspect that if the DEP was clearer in scope and aims, these concerns >> > would not actually arise >> >> Debian infrastructure is "centralized" in many ways. The power to decide >> which packages go in the archive and which do not is "centralized" in the FTP >> team, and you must upload to a "centralized" machine for them to review. >> buildds build the public facing packages, debci runs migration reference >> tests, they are all "centralized" on a few hosts and in a few people. >> Packages are distributed from a single source (mirrors don't have the say of >> the content). Even the very list you are posting to is hosted on a >> centralized machine. How would storing packaging sources on a centralized >> code hosting instance be different than package distribution? How would a >> centralized CI be different than buildds and debci? >> >> The more important decentralization is in the decision process. Not >> everything is fit for decentralization; don't push it only for the sake of >> it. >> >> GitLab isn't perfect, sure, but it's an implementation detail of having a >> centralized code hosting and CI. I'd personally expect the CI to be basically >> the same as debci (maybe even merge the two or make salsa delegate CI to >> debci), but that's another topic. > > Yes, some parts of Debian are centralized, but it seems you turn those into > reasons for giving up on the flexibility of others which are not. Well, I didn't mean we should *give up* decentralization. I mean we shouldn't give up *centralization*. These examples are to prove centralization actually works and is quite common, sometimes necessary. > I have worked in areas with weak internet connection (near the Amazonas > jungle in Peru, and at the country side of Sweden) where I could have a > full mirror of Debian and an archive of email conversations, and from > that not only release package updates but also work on developing Debian > Pure Blends (i.e. "forks" of Debian containing purely Debian parts), > with only occational need to syncronize my data with Debian. > > I don't say that Debian must work for jungle developers, nor that we > must all use email and not different forms of collaboration requiring > better connectivity. My point is that Debian *allows* collaboration > also without heavy realtime connectivity that most of us take for > granted in our working environments, and I fail to see why the few > points that are centralized is a reason for giving up on all the others > as well. And I did not push "realtime connectivity" either. All I'm saying is that centralization isn't inherently bad, it's a characteristic with benefits and tradeoffs. It's also not inherently synchronous, just means a single source of truth. Well, some aspects are, but not all. That said, your example, package releases, *is* synchronous. It's totally fine to work on one aspect while your coworkers work on another, only exchanging progress now and then, but I imagine it'd be a mess if you each decide to release on one's own. The release point inevitably requires all work to be synchronized to a single source of truth, from where a canonical release is produced. It's of course not necessary if you are a lone wolf, but we are trying to avoid that. Besides, *you* are the centralization point when you are the only maintainer. With a centralized code hosting, you exchange being SPOF with redundancy and team work :p -- Sdrager, Blair Noctis
OpenPGP_0xC21D9AD423A39727.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
