Re: Proposal: Repository for fast-paced package backports
I like the general direction, but there are some aspects of your
>which should be improved.
>> 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
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
>Given the nature of the packages in "fastpaced", it's counterproductive
>to mandate the same standards as for the standard archive, it rather
>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
>dependencies which can no longer be fulfilled from stable as upstream
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
I am open to this, as long as the goals to have full compatibility with backports stay the same.