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