Upstream rolling releases and version control
Hi,
On Mon, Feb 10, 2020 at 05:17:38PM +1100, Dmitry Smirnov wrote:
> In case of Gitlab I recognise that Salsa could not be maintained from the
> official packages. They are too fragile, often uninstallable even in
> "unstable" and depend on unofficial "fasttrack" repository. There are too
> many dependencies and things get broken far to often in too many places.
> In theory Gitlab could be in a better shape with larger team, but in the
> current situation I see why Salsa operates from vendor container image and it
> is reasonable.
If the packages are unusable for us, then they are likely to be unusable
for a lot of other people as well. If it's the nature of the software that
stable releases don't make sense, then not having them as part of a stable
release is a sound technical decision.
I've filed RC bugs "this package should not be part of a stable release"
against my own packages a few times already when it looked as if upstream
was unable or unwilling to support anything but the bleeding edge versions.
CI and releases are kind of antithetical. They wouldn't have to be, but
this is the way the culture around CI developed.
>From a Debian POV, we should have a discussion on what that means for
packaging:
- how do we handle packages that have no stable releases at all?
Some packages, like piglit, are still useful even as a frozen-in-time
development version. On the other end of the scale, we have clients for
protocols that change often as the service develops, and where users are
expected to upgrade to the latest client.
- how can we better integrate different package ecosystems?
There are a lot of language-specific package managers, like npm, build
systems that pull in packages like gradle, and services like docker that
all provide package management that runs in parallel with .deb packages,
and has different update policies than the Debian archive.
- how can we better integrate non-Debian version control?
Fundamentally, the Debian archive is a kind of early distributed version
control system, implemented on top of dumb file storage and file transfer
protocols. If we exchange the lower layers, then suddenly the upper layers
reimplement part of their functionality in a conflicting way, which is why
building packages from git is a mess of scripts.
All three are long-overdue discussions on how to adapt to the changing
times.
Simon
Reply to: