On Sun, 26 Jan 2025 at 09:04:52 +0100, Rene Engelhard wrote:
> Am 26.01.25 um 02:07 schrieb Otto Kekäläinen:
> > Personally if I have some features that are not ready to be uploaded
> > for a long time, I would maintain them in a 'feature branch'. In some
> > cases that feature branch might live as a MR that is open for a very
> > long time.
>
> But then it's not "latest". I would call whet is in experimental for
> libreoffice "latest". Especially next week when 25.2.0 will be released
> 25.2.0 is the "latest" upstream final release, and 24.8.x is not :)
DEP-14 has naming schemes for two reasonable workflows, and I think a
lot of criticisms of it are assuming that one of them is the only one
and disregarding the other.
In the GNOME team we use debian/latest (the default branch in the git
repo) for the newest upstream version that we're packaging (whether
that's for unstable or experimental), and if necessary we create a
debian/trixie or debian/unstable branch for updates that target testing
and unstable while we already have a version in experimental. src:gtk4
and src:mutter are good examples. This is good if most of the package's
Debian maintainers are mostly focused on the development branch and
making few changes to the more-stable branch, or if the lifetime of a
development branch is quite short (6 months for GNOME).
When maintaining dbus and flatpak I use a different workflow, where the
default branch in the git repo is debian/unstable, and there's a parallel
debian/experimental branch for newer upstream releases that aren't
ready for unstable. At the moment both are inactive because the latest
upstream release of both dbus and flatpak is a stable 1.16.x release
(this is not coincidence, with my upstream hat on I made sure both would
be ready in time for trixie), but use of the debian/experimental branch
will resume as soon as we get a 1.17.0 development release. This is good
if the lifetime of the development branch is relatively long (generally
more like 1-3 years for dbus and flatpak), and bug fixing in the stable
branch is getting more Debian-maintainer attention.
Both workflows make sense, DEP-14 explicitly allows for both, and I think
it's an oversimplification to dismiss either one as never appropriate. Our
workflows should be as simple as possible, but no simpler.
It sounds as though, if you were using DEP-14 for LO, you would want
the workflow used in dbus and flatpak (with no debian/latest branch),
and not the workflow used in GNOME (with a debian/latest branch as
default). And that's fine! If I didn't think that was fine, I wouldn't
have chosen it for dbus and flatpak.
I think the debian/latest workflow (as used by the GNOME team) is a
better default to suggest to new maintainers, and a better default for
typical non-key packages where the upstream developer doesn't maintain
long-lived stable branches and the package doesn't usually have a
version in experimental. dbus is not a typical package; neither is LO,
and neither are things like gcc, systemd and the kernel. We should make
sure our policies accommodate these atypical packages, because many of
them are very important OS components, but we shouldn't necessarily let
them determine the defaults that we use for 90% of the archive.
I hope that makes sense?
I think this is an example of a wider design principle: defaults are
for the common case, and for inexperienced users (or in this case,
inexperienced developers) who have no basis for choosing whether they
want something non-default. It's OK if experienced users/developers
will often want to do something non-default to accommodate their more
complicated situation, because by the time they find themselves in that
more complicated situation, hopefully they're experienced enough to
make good decisions about how they will move away from the defaults,
and understand the cost vs. benefit of doing so.
smcv
