gnu-linux-libre
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU-linux-libre] review of uruk


From: bill-auger
Subject: Re: [GNU-linux-libre] review of uruk
Date: Tue, 28 Mar 2023 21:49:18 -0400

On Wed, 29 Mar 2023 02:31:57 +0200 Denis wrote:
> 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).

its probably all of those things - i prefer to be as rigorous
as possible though - at least to sort things out, make some
determinations, and most importantly, to docujments them and
apply them, rather then leaving unnecessarily vague things remain
vague and contentious - arguments about the vagueness of the
FSDG, account for the majority of time spent on this mailing
list - it is very inefficient


On Wed, 29 Mar 2023 02:31:57 +0200 Denis wrote:
> 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)
> 
> A requirement like that would also forbid using savannah for hosting
> your source code, forbid secondary mirrors managed by the project, etc.

to sort that out: there is a huge difference between GNU
managing the infra for GNU projects, vs relying on a completely
unrelated third-party, which has no obligation to provide those
services to the project - GNU is obligated to GNU projects -
pureos is not obligated to uruk in the same way (not in any way,
in fact) - pureos has every right to obstruct uruk users from
accessing their servers

likewise, hosting your source code on a third-party forge is
still very different - i would recommend against that; but still,
the project has sufficient autonomy using forges - they can
decide what goes in or out of it, fix bugs, and so on - i would
consider that as sufficiently providing and maintaining that
source code - but in this case, the majority of the software in
uruk, is literally "not provided" nor maintained by that distro
- the distro maintainers have zero control over the majority of
the software that their users use

i think that discrepancy is very significant - the distro should
have complete autonomy over all distributed software - all that
uruk would need to do, is to mirror the pureos repos, to gain
complete autonomy to filter it, or replace packages with
bug-fixed versions, etc

that may be a adequate clarification, what i would add to the
"complete distros" section:

> Distro maintainers must have complete autonomy over all software that they 
> distribute.

i really dont think that is expecting too much - i would tend to
see it as essential, if i were choosing a distro

despite my preference on this topic, i would like to concede
this for now - i have offered a proposal to accommodate this
situation, as something of a concession - maybe that would
satisfy everyone


On Wed, 29 Mar 2023 02:31:57 +0200 Denis wrote:
> 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.

its really all we can do now - my concern now is only of the
future - it appears to me, that this review of uruk is going to
get snagged against the past unresolved problems with the FSDG
itself - it has already gotten snagged on the mis-management
problem; but there are others lurking ahead on the path - the
kernel in that repo is another major unresolved conflict for
this work-group

indeed, most of the review could be done now, and i think that it
should be; but IMHO this distro should not be able to pass review
on the face of it, due to the current circumstances - the FSDG
status of pureos is contingent on the resolution of two major
long-standing unresolved conflicts - i am not comfortable
bringing in another with the same contingencies, until those
conflicts get resolved

in fact i am not pleased to be involved in this work-group at
all, until those conflicts get resolved



reply via email to

[Prev in Thread] Current Thread [Next in Thread]