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.
