Re: Proposal: Repository for fast-paced package backports
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
Reply to: