On 2018-12-18 18:40, Pirate Praveen wrote:
On 12/18/18 8:41 PM, Holger Levsen wrote:On Tue, Dec 18, 2018 at 08:38:39PM +0530, Pirate Praveen wrote:But if that is not possible, volatile as a separate archive is also fine.instead of volatile we need PPAs.I think a redefined volatile is the best option for sharing work. But PPA approach is best in case of conflicts. I'm leaning towards volatile and hence I proposed it. If you feel strongly about PPAs, please propose and drive it. Either option will work for me.
Just for the record - I know you say "a redefined volatile" - and as a former volatile team member: This would in no way have been suitable for volatile either. Just like backports the assumption is that the packages are up to Debian's quality standards and we make the result available to users of stable earlier. Volatile's mission statement was keeping software like virus scanners actually useful while doing minimal changes to stable and that was the main reason for folding it into the regular release as well as creating -updates to have a timely push mechanism.[1]
In the Ubuntu PPA case you get free reign over what's in that archive and what you backport as part of offering the package. Obviously this might conflict with the existing set. But the same is true for a centralized volatile archive if you need to backport a large set of build dependencies to make the whole thing work in the first place. And I'm sure you wouldn't just go for a gitlab source package with bundled build dependencies.
Now the policy question of who can ship what in a way that looks semi-officially as being part of Debian is tricky. I personally find the notion that testing should just be the staging ground for the next release to be unfortunate but at the same time know how we ended up with it. Maybe there's a place for packages that cannot usefully be supported for a stable release and hence need to live in parallel. But then again I wonder if the answer wouldn't be an archive where the input is built for all suites and where the dependencies are bundled - if only because you'd track upstream closely and would through that (hopefully) pull in necessary security updates.
Kind regards Philipp Kern[1] And to some degree I am unhappy with backports' team's antagonistic view on volatile here. Stuff like gitlab would have been rejected in the same way it would've been in backports. The useful bits live on, it wasn't abandoned to cause more work for backports. At the same time backports can serve as a replacement of a subset of use cases too, where its rules fit just fine.