]] Bas Wijnen
> Debian stable is for users who want a rock solid system. It is out of date by
> the nature of how it is built. Users who want to get the newest versions of
> their software should not be running stable; testing is probably better for
> them.
This often isn't what users want, though. They want the newer versions
of some packages: On my server, I want a new weechat (since it has
bugfixes and features I use), I want a newer grafana (ditto). I don't
care about having a newer version of emacs, the version in stable is
fine. Ditto for, say, postgres.
Other users are going to care about different sets of packages, but we
all have the same «I want stable, but for $list_of_packages».
Maybe backports is what we decide is the best solution for those cases,
but maybe we can do better than that.
> > We have zero procedure in place for the following:
> >
> > - Totally unsupported very old version of ${FOO} in stable, maintainer
> > isn't patching bugs, bugs are going to upstream, and upstream is
> > annoyed Debian has out of date, perhaps insecure thing X.
>
> Yes, this is a different problem. We may want to shield upstream from
> bugreports for those packages somehow.
I'm not at all convinced we can shield upstreams, since users will show
up on mailing lists and IRC upstream and go «I'm trying to do $X, but it
doesn't work, and according to the online docs, it should» and after a
bit of a back and forth, it's discovered that they're running an old
version which either lacks the feature or where it's broken.
> IMO it would be good to recommend our users to file all bugs with us,
> and leave it to the maintainer to pass them to upstream. I have
> upstreams that follow our bug tracker, which is great. But if they
> don't, it should be up to me to decide whether the report is worth
> their time.
A lot of user interaction isn't bug reports, but rather closer to user
support. I don't think it's reasonable for maintainers to be asked to
do all the user support that upstream does. Even just handling bugs
well (triaging and in some cases fixing and sending patches upstream) is
a lot of work.
> > Hell, teams packaging Mozilla-soft and PostgreSQL are DDs maintaining
> > *external archives* because it's easier.
>
> This indicates that our procedures are too hard. That needs to be fixed.
> Maybe people from those teams are reading this and can comment on it?
No, it doesn't merely indicate that our procedures are «too hard». I
think apt.postgresql.org exists because PostgreSQL.org themselves want
to provide a service to our common users. We don't want to have all the
supported postgresql versions in our distro, but it's super useful for
users who need a particular version.
> > Making it hard to install a new archive will only lead to more
> > workarounds, more FAQs telling users to dismiss warnings, and more
> > upstreams hell-bent on working against us, because we keep making their
> > lives harder.
>
> Yes. But I'm reluctant to throw away our stable release process. If it's not
> for everyone (and it isn't), we should be more clear about that.
I haven't seen anybody advocating throwing away our stable release
process. So far it's mostly pointing out problems, not yet trying to
come up with solutions. (Which is fine, we need to find out what the
problems and the pain points are before it's useful to come up with
solutions.)
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
