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

Re: Summary of the current state of the tag2upload discussion



Micha Lenk <micha@debian.org> writes:

> thank you, Russ, for summarizing the discussion so far.  As far as it
> represents the tag2upload proponents point of view, I think it is a fair
> summary of what was said so far.  A few aspects seem to be missing from
> my point of view, so I'd like to share my own opinion (I don't know
> whether it qualifies as a reasonable complement to Russ's summary).

Thank you for this!  I'm very glad to see other people posting summaries
of where they think the discussion is at, and I think this was a good
addition.  There are a few things about which we disagree (for example, I
think it's incorrect to say that tag2upload would sacrifice source package
verifiability down to individual developers, although it's true that it
changes the shape of that verification), but I think those are topics
about which I don't have anything new to say.

I did want to address your point about a more comprehensive revision of
how we think about source packages, though, because I did indeed omit that
from my summary, there was a reason, and I probably should have said what
the reason was.

> Russ's summary seems to miss the questions Paul R. Tagliamonte raised in
> [1] and extending on in [2].  In essence, what do we consider as source
> after all?

> [1.] https://lists.debian.org/debian-vote/2024/06/msg00363.html
> [2.] https://lists.debian.org/debian-vote/2024/06/msg00424.html

The reason why I didn't participate in that discussion, and the reason why
I didn't try to summarize it, is that I don't believe anything will ever
come of it.  I don't think these more radical approaches will ever be
implemented, and if implemented, I don't think Debian will ever deploy
them.  Or, at least, that none of this will happen in any reasonable time
frame.

I know this sounds very negative, and I don't mean this to be stop energy
for people who want to work on this.  I would be absolutely thrilled to be
proven wrong.  That would make me very happy.  And therefore I stay out of
the discussion so that I don't just inject negativity.

But I've seen this pattern before.  I remember 3.0 (git).  And I remember
a lot of other discussions over the years that didn't get as far as 3.0
(git) got, discussions full of grand ideas and not much implementation
follow-through.

Debian is full of people who love to design things and love to talk about
other people's designs and love to look at the big picture.  But it's one
thing to design something, it's another thing to implement it, and it's
yet another thing to deploy it, and Debian is passively hostile to change
of this type to a degree that I don't think people realize until they've
tried to do it.

Worse, this is frequently used, as I feel is happening to some degree
here, as a justification for blocking work that has already been done.

I do think we should review major changes to ensure that they don't create
serious new problems, and we have also failed on that score in the past.
That's part of why I invested a lot of effort in trying to help check that
in this case.  And you may disagree with my evaluation there.  But what I
would ask is to separate that from the question of what we ideally should
do, separate it from how you would like to see the work done, and be very
precise and clear about whether there is an actual, serious problem.  Not
just "less than ideal" or "not any better than what we already have" or
"we could solve so many more problems with a more radical design."

We should err on the side of letting people deploy their work.  If they
have spent a long time working on a problem, with actual code, tested with
real packages, we should default to believing that they are correct in
their analysis of the problem.  Or at least correct enough to use their
work, even if it falls short of what we hope we can eventually do.

Blocking people's work beause it's actively dangerous, sure, sometimes we
have to do that and it sucks but it may make sense.  But blocking people's
work because it didn't solve a larger problem than they wanted to solve,
or cared more about backward compatibility than one might wish, or changed
a security model in a way that's a little better in places and a little
worse than others... that just feels wrong to me.  Rude.  Dismissive.  And
self-defeating for Debian as a whole.

I do not in any way want to interfere with the work of people who want to
tackle a bigger problem.  There is definitely a bigger problem here, and
there are things that we could do way better than we do today.  I
personally have been sufficiently burned on this front that I am no longer
participating, but I will cheer you on from the sidelines, very sincerely.
I want you to succeed.

But, in the meantime, I want to deploy the work that is already done and
that will make my life better today.  And I would ask people to consider
the serious possibility, based on a lot of past evidence, that saying no
means we get nothing at all, because the people who could have evolved
their work into something better took no for an answer and found something
else to do with their time.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>


Reply to: