On Mon, 27 Mar 2023 10:56:47 -0400 bill-auger <bill-auger@peers.community> wrote:
> On Mon, 27 Mar 2023 16:31:51 +0200 Denis wrote: > > As I understand, self-hosting has a completely different meaning > > here: it's not about hosting your own infrastructure and it has > > nothing to do with infrastructure at all. > > i really think it implies both - the word "provide" would make > no sense, if the distro does not provide the software, but > refers users to a third-party, who has no obligation to provide > anything to those users Self-hosting is kind of defined as: > In particular, a free system distribution should be self-hosting. > This means that you must be able to develop and build the system with > tools that the system provides you. As a result, a free system > distribution cannot include free software that can only be built by > using nonfree software. So if you install Replicant on a device, you can't build Replicant (the system) with tools that the system provides you. This most likely applies to LibreCMC and ProteanOS too: You probably don't have packages in LibreCMC that enable you to build LibreCMC on a computer running LibreCMC, though I'm not aware of somebody that tried to do that[1]. Then we have: > We make an exception to this requirement for small system > distributions, which are distros designed for devices with limited > resources, like a wireless router for example. Free small system > distributions do not need to be self-hosting or complete, because it > is impractical to do development on such a system, but it must be > developable and buildable on top of a free complete system > distribution from our list of distributions, perhaps with the aid of > free tools distributed alongside the small system distribution itself. So here "small" fits well for cases like LibreCMC where some supported devices have 8MiB of storage space, so that makes it "impractical to do development on such a system". You could probably add external storage, mount an NFS share, etc, though that is not very practical as probably not all devices have usb host. Here I don't think these two paragraph have something to do with where the web server of the project homepage is running. That said, there may or may not be requirements that are not in the FSDG (for instance if the FSDG is not complete, or because no one though of new problematic cases or issues, or just because some class of problems usually never happens for one reason or another). And I think that not self-hosting your own infrastructure is not necessarily a binary situation: for instance Guix doesn't control all its infrastructure (because GNU, not Guix controls part of it), but Guix is part of the GNU project and GNU probably controls all or at least most of its infrastructure. A requirement like that would also forbid using savannah for hosting your source code, forbid secondary mirrors managed by the project, etc. Though a possible way to improve that would be to see if/how the FSDG could rely on the "GNU ethical repository criteria" for instance and require a better grade than F. Though the downside is that it would require to review the forges being used as well. Also having parts about "SASS" would probably be a better fit than requiring things about self-hosting your own infrastructure. If we'd want to define infrastructure self-hosting, there is a collective called CHATONS / KITTENS that has a charter about hosting that defines the CHATONS obligations toward users, that could probably be reused somehow to define infrastructure self-hosting requirements[2] as they have to self-host to provide services to its users (which are not self-hosted as the CHATON host things for users). And inside that charter there are clauses like that: > the CHATON must have root access on the operating system running the > final online services; So here if some trusted entity that isn't the distribution (like the FSF for instance) provides a mirror or some space to host files operated by the project: - If we have some not-SASS requirements, here it's not SASS so it should be OK. - If we have some the-distro-needs-to-self-host-its-infrastructure requirement it's not OK anymore because this is not self-hosting. If needed, extra requirements could probably then be added (if they make sense) to for instance make sure that users are not spied on by the mirrors for instance, that the mirror content is under the distro control somehow, etc. Though a document detailing all that would probably also be useful for other cases, like hosting releases, websites and so on for projects (like GNU software or other projects that want to use such criteria). At least some GNU toolchain components (through Sourceware) have a separate infrastructure from GNU, so there may already be some requirements or information somewhere about the infrastructure that could be reused. Though for now it's probably easier to just focus on the review of uruk right now and for things that are not inside the FSDG, to request changes like that on the basis of making the review faster. For instance moving away from sourceforge is probably a good idea since we don't need to discuss a lot about if it's acceptable or not, we also don't need to review sourceforge, look at its JavaScript, etc. In general, doing like the other distributions whenever possible would also make it easier and faster to review it. In any case, beside the review, we are also waiting for information on various topics like on the released ISOs for instance. References: ----------- [1]To try you'd need to first build LibreCMC for x86 (all the times that I tried it worked), and through trial and errors see if there are the packages required in LibreCMC to build LibreCMC. For ProteanOS I don't know enough about it but it looks like not-self hosting from its website documentation. [2]https://www.chatons.org/en/charte Denis.
pgpu93E5Vlcn_.pgp
Description: OpenPGP digital signature
