On Fri, 2 Aug 2024 at 12:48, Simon McVittie <s...@debian.org> wrote: > > On Fri, 02 Aug 2024 at 11:35:54 +0100, Luca Boccassi wrote: > > VERSION_CODENAME=trixie was added, and the problem as explained is > > that it's present in sid too. So the only identifier we have in sid, > > identifies it as trixie, which is categorically and unequivocally > > wrong. > > When involved in a disagreement, please could you try to make an effort > to understand the point of view of the other side, rather than declaring > them to be categorically and unequivocally wrong? I think that would > lead to fewer people feeling that they're being shouted at and refusing > to engage with you, which is likely to result in more of the changes > you want to see actually being adopted.
Some things are viewpoints, and then there are such things as facts. As mentioned in another mail, one is of course allowed to say "it is fine if the os-release implementation in debian is buggy". One can say "the severity of this bug is nil". One can say "it is better if the bug is not solved". One doesn't even have to state a reason for such a belief, and it's perfectly valid nonetheless. That's a viewpoint. It is not a "viewpoint" to say "the os-release implementation in debian is not buggy", because it's not a competing opinion or design choice, it's denying a fact that exists independently of opinions, for reasons already explained at length, that I am not going to repeat yet again. One can disagree on the severity of the bug and think it is nil, one can disagree on whether it should be fixed or how. It is still a bug. Why is it a problem to define it as such? Why is saying "the spec says A, this does B, therefore it's a bug" equivalent to "shouting" or "insulting"? If this was a running program and it checked the state according to the spec and assert on it, it would crash. Whether one holds the view that it would be right or wrong to crash, it would still crash, and there's no point in denying it would, and I don't see how it helps with resolving anything or making any progress. > In this case, I think the two design principles might be: > > - you think of sid as an independent rolling-release distribution in > its own right, an alternative to e.g. Arch Linux, and so you want to > label sid images/containers/chroots/etc. in a way that is consistent > with that point of view; I don't think that's accurate. It's not an opinion that one can run "debootstrap sid", install it, run it, and never ever reach any point in time where that is a stable, security supported os vendor tree that will go EOL and have a version+1. This is a fact. We know for a fact that this happens, today, yesterday and tomorrow, in the real world. It is also a fact that due to this, the os-release specification mandates certain things to be defined in its metadata, that are currently not done today, and that some that are done, shouldn't. It is an opinion that I think this should be fixed, and it is also an opinion that fixing it is more important than other competing concerns. It is an opinion to say that it is better to leave it as-is. > - Santiago thinks of sid as a tool to be used as part of the process of > making our next stable release, an alternative to e.g. Fedora Rawhide, > and wants to label sid images/etc. in a way that is consistent with > *that* point of view That's not an opinion either. It is a fact that sid is a tool used to develop the next stable release. I recognize that fact, and I do not want to change it. My understanding is that Santiago's opinion is that fact is a reason enough to avoid fixing the above issue, because labeling is incompatible with <something that I do not quite understand to be perfectly honest>, and because sid and trixie must remain undistinguishable because they are the same thing. It is my opinion that labeling does not impede on the goal of sid being a tool to develop the next stable release, and it is a fact that the os-release specification is not incompatible with this situation, and it is my opinion that we should change this implementation, and it is my opinion that it would not negatively affect sid's purpose and role in our development model, and it is my opinion that trixie and sid should be distinguishable, and it is a fact that trixie and sid being distinguishable would fix a bug in the os-release implementation. > I think that, as a project, we need a lot more willingness to frame > disagreements in terms of "I see your point, but I think my point is > more important", and a lot less "you're just wrong". All of us are > doing our best to make Debian the best possible Free operating system, > even if we don't always agree on precisely what that means. I don't see saying "this is a bug" as "I don't see your point" or "you are just wrong". I see it as stating a fact. This is my opinion on it being a fact and not an opinio... ok I am getting entangled now. The point of saying "this is a bug" is to clarify what is an opinion and what isn't, without having to pedantically pre-label everything as I have just done in this frankly unreadable reply. The purpose is to establish facts, and then argue about severity and solutions and their merits or lack thereof.
