Re: general policies

[Denis 'GNUtoo' Carikli]

On Tue, 19 Sep 2023 23:19:14 -0400
bill-auger <bill-auger@peers.community> wrote:
> the only long discussions should be about the guidelines themselves,
> not any individual programs - very few programs are so unique to
> require its own discussion (eg: the recent scummvm discussion was an
> exemplary waste of time) - i say, spend that time working out a
> general policy, then each example becomes simply: "... and scummvm is
> one of those - treat it just like the others, as prescribed" - that
> approach may sacrifice some precision, but is far more efficient
Both probably go hand in hand here. There is already a lot of
complexity so having to decide on 100% abstract notions is probably too
complex. We also need to see how these decisions would work in practice
if we want them to work.

If we decide something about ScummVM the decision has some rationales
that can be applied to other programs in similar cases. And if ScummVM
changes, what to do with it can also change, but that's not exactly
what I was advocating for, because as you point out that has some
drawbacks:
> that is more practical; but that approach tends to lead to a
> patchwork of contradictions, inviting uncomfortable questions from
> users that i do not want to answer, like "why did they treat program
> A with treatment T, but not program B which has identical
> properties?" - answer: "because they (possibly different people) did
> it ad-hoc and subjectively, without a uniform general perspective"

I was not really advocating for or against very narrow decisions but
rather simple decisions. Simple decisions can also be broad. The
difference is that they don't open very complex can of worms and
endless discussions that never end. 

And so step by step they can be used to build some better understanding
of how to deal with corner cases.

And the fact that they are simple makes it easier not to take decisions
that need to be reverted later with trickling impact on all the
existing data.

Example: decide on dependencies before depending on the use of third
party repositories or other operating systems, clarify dependencies to
better apply to existing uses programs, etc. Then this allows to add
more programs, and potentially discover new issues. 

We can also be more strict on some criteria in order to limit potential
long term damage and again better foresee other issues. For instance
only officially allow other OS / firmwares being packaged in existing
FSDG distributions. Then we could open that up to more firmwares and
verify that they are buildable on FSDG distros, etc.

And about GNU, even if there is a big effort for consistency, the
various packages being maintained there still seems to have big
variations. And it's to be expected since they cover different use
cases. 

For instance Emacs is way older than Guix. Some packages are written in
C, other in scheme. At least one is written in shell (gnuboot) and
another in C++ (gnash). Taler also has many implementations in many
languages. Some use the GNU infrastructure, other use their own
(packages maintained by sourceware).

Other have a mix of both. Some also work on nonfree OS some don't. Some
are core infrastructure, some other are games, or software for very
specific fields (electronic design, specific scientific fields, etc).
Some are experimental other are very stable. Some are made from
scratch, other are based on existing projects they deblob (like
linux-libre).

And the fact that some of them are old like GCC doesn't make them
not-relevant anymore, especially when they benefit form cutting edge
research on compiler optimizations.

So for instance if Emacs was or is evaluating changing its default to
more common shortcuts like ctrl+c, ctrl+f and trying to find a way that
doesn't break old and new users setups, it doesn't mean that the
situation with Guix or GNU in general is similar.

I took some space and time to clarify that (hoping that I didn't do any
mistake here) as there is also some propaganda against GNU in general
that use this idea that GNU is old and that people should try not
to use it because of that and use newer things instead.

This also raises some questions as what matters more. Freedom, good
maintenance, features, use cases coverage, diversity of the
community, attractiveness of the software, security, simplicity, etc are
probably way more important than some vague notion of new.

Denis.

pgpTPWDSNx_X9.pgp
Description: OpenPGP digital signature