Re: Proposal: Repository for fast-paced package backports

[Dominik George <natureshadow@debian.org>]

Hi,

I like the general direction, but there are some aspects of your
>proposal
>which should be improved.

Thanks!

>> Other ideas: fastlane, unsupported
>
>Or maybe something like "fastpaced", after all this repo would not be
>unsupported at all, the very point is to provide actual support after
>all.

I actually think volatile is a good name. After all, it's not so far from the previous volatile.

>>  - The package must be maintained in unstable, like every other
>package.
>
>Given the nature of the packages in "fastpaced", it's counterproductive
>to mandate the same standards as for the standard archive, it rather
>makes
>sense to relax some aspects.
>
>E.g. we usually try to avoid embedded code copies. But for a package
>like Gitlab that doesn't really add any value, if an embedded Ruby
>package is affected, Gitlab upstream fixes it in their weekly release
>anyway. And if not using the embedded code copies you'll end up with
>plenty of
>dependencies which can no longer be fulfilled from stable as upstream
>moves forward.

The intention is to keep the way open to have a real backport again should the situation change. I find that very important for compatibility and assuring upgrade paths.

>> I propose to add the volatile repository next to the backports
>> repository, and treat it as part of backports.
>
>I wouldn't tie this to backports at all, rather make it a separate
>section of the archive and have some ACL mechanism to allow the DDs
>maintaining a fastpaced package to grant access to it (similar to
>#817285).

I am open to this, as long as the goals to have full compatibility with backports stay the same.

-nik