On 3/17/24 11:39, Lars-Dominik Braun wrote:
Hey,
I have heard folks in the Guix maintenance sphere claim that
we
never rewrite git history in Guix, as a matter of policy. I
believe
we should revisit that policy (is it actually written
anywhere?)
with an eye towards possible exceptions, and develop a
mechanism for
securely maintaining continuity of Guix installations after
history
has been rewritten so that we maintain this as a technical
possibility in the future, even if we should choose to use it
sparingly.
the fallout of rewriting Guix’ git history would be
devastating. It
would break every single Guix installation, because
a) `guix pull` authenticates commits and we might lose our
trust anchor
if we rewrite history earlier than the introduction of this
feature,
b) `guix pull` outright rejects changes to the commit history
to prevent
downgrade attacks.
Additionally it would break every single existing usage of the
time machine and thereby completely defeat the goal of
providing
reproducible software environments since the commit hash is
used to
identify the point in time to jump to.
I doubt developing “mechanisms” – whatever they look like –
would
be worth the effort. Our contributors matter, but so do our
users. Never
ever rewriting our git history is a tradeoff we should make for
our users.
Lars
Thats a good point. in the sense that its a tradeoff here and I
absolutely agree.
But let me add some food for thought here:
1. Were the social aspects considered when the system came into
place?
2. Is it more important for the system to stay as is than to
welcome
new contributors?
3. You mention "its a tradeoff we should make for our
users". How many
trans people where involved in that decision and how much did
their
opinion matter in this?
I am saying this because giving power to people(what is called
users)
is not only handling them code or make sure everything is free
software.
Its also the hard part of making sure the voices of people that
can
not code is heard and is participating and taking in mind.