[DRE-maint] Bug#915050: Proposal: Repository for fast-paced package backports

[Utkarsh Gupta]

Hi Dominik,

On 26/12/18 2:16 am, Dominik George wrote:
> Heisann, alle sammen,
>
> as announced in the recent thread about maintaining, I hereby propose a
> repository that allows making “backports” of packages available to users
> of the stable distribution, if those packages cannot be maintained in
> testing and backported in the usual way. If you are interested in what
> lead up to that, please see bug #915050. I will give a short summary of
> it here.
>
>
> Reasons for having a special place for some packages
> ====================================================
>
> (You may want to skip this part if you are familiar with the situation.)
>
> As all developers know (but passers-by may not), for software to enter
> the Debian archive, it is always uploaded to the unstable distribution,
> then migrates to testing (hopefully ;)), which is at some point snapshot
> and made the new stable release. From there on, maintainers have two
> obligations: Firstly, keep the package in stable good and secure, e.g.
> by uploading security fixes for it once they become available upstream,
> or even backport fixes themselves. Secondly, provide the package in
> unstable with updates and ensure its migration, to keep it ready for the
> next stable release.
>
> Now, for some software packages, this process is problematic, because
> upstream may have another idea about software lifecycles. Concerning the
> GitLab example, upstream provides security fixes for three months for
> their stable releases. Backporting fixes from newer versions is very
> hard or impossible because the massive amounts of changes to the
> software in every new versions. This is something that also affects
> other packages, like Mozilla Firefox, which has a firefox package in
> unstable, and a separate firefox-esr package, with the ESR version of
> Firefox. Only the latter migrates to testing.
>
> Users of Debian honour it for its stability, but as an agile software
> lifecycle is adapted by more and more very popular software packages,
> not being able to install these packages in the trusted, well-known
> fashion through the official apt repositories is becoming more and more
> of a drawback.
>
> It can easily be assumed that the normal release and maintenance cycle
> of Debian stable will not change, which is very good, so we should find
> a way to still provide such software as described above to users.
>
>
> Why backports is not enough
> ===========================
>
> This also is well-known, but for completeness: Formal backports in
> stable-backports are required to be direct backports from testing, and
> are a stepping stone within the upgrade from stable to stable+1. Thus, a
> version of a package that is not in testing can never be in
> stable-backports.
>
> <snipped>
>
> Implications for the situation at hand (gitlab)
> ===============================================
>
> As there were quite a few concerns raised (some of which I share, and
> some I don’t): Of course, if a software intended for volatile has a ton
> of dependencies (intended to go into backports), all backports rules and
> powers of the ftp-masters apply. Repeating myself: volatile is not meant
> to ease the life of maintainers.

Did you get a chance to work on it?
This is mostly in reference to #915050. Since GitLab is in good shape
now (people have their own perception of good, though), we'd like to
fast track this and take this forward. 

Let us know about the same :)


Best,
Utkarsh


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-ruby-extras-maintainers/attachments/20190520/4bc8ea00/attachment.sig>