Re: Why Debian is dying (Was: Call for volunteers and GR draft: tag2upload key installation)

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Daniel Gröber writes ("Why Debian is dying (Was: Call for volunteers and GR draft: tag2upload key installation)"):
> [much that I agree with snipped]

Thanks.

> # FTP & tag2upload
> 
> Ian. The project is bleeding and you're telling me ... we've had the
> bandaid ... in hand ... and could have applied it ... four years ago!?

To be clear, tag2upload is only a part of the solution to the problems
you identified.  (And it's not the *only* proposed solution even in
its own space - but it's the only proposal that's part of a git-first
programme for Debian and also the only one that actually exists.)

But, yes.

> Ian, you have my full support in doing what is necessary to stop the
> bleeding and I'll be happy to volunteer to help with the dak hack job if
> that still makes sense with Simon's keyring idea on the table.

Thank you.

Yes, changes to dak are still needed, even assuming that we everyone
is happy with the new debian-tag2upload keyring that I've prepared a
git branch for and submitted in #1102125.

We still need at least a configuration change to cause dak to look at
that keyring as well as debian-keyring.gpg.  IDK if dak's code
currently supports provision of more than one "Debian developer
keyring"; if not then that would have to be done too.

But anyway, this is trivial stuff.

> the five (at least, right?) different flavors of git packaging repo
> layouts

Five.  lol.  I surveyed them in 2019 or so, as background research work:

  https://wiki.debian.org/GitPackagingSurvey

My personal opinion is that *at the very most* four of them ought to
exist in a git-first world.  All the others are either not git based,
or pareto-worse than some other row in the table.

The four that are git-based *and* not pareto-worse than some other
approach are "unapplied", "merging", "git-debrebase" and
"git-debcherry".

The reason there are as many as four there is that we're maintaining a
downstream patch queue, and maintaining and updating and sharing a
such a downstream patch queue, with git, is an open research problem.

This hard problem is one that "the youth of today" largely won't have
had to deal with, since they have the upstream-first mindset as you
say.  So there is some irreducible complexity here, but even so we
could and should do a lot better.

(I obviously approve of an upstream-first mindset, but it falls down
when upstream isn't working well.)

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.