Just few answers derived from common sense: On Thursday, 3 October 2019 7:23:41 AM AEST Bernd Zeimetz wrote: > - how do you want to avoid that this service becomes a mess?
We don't have a perfect solution for this problem in the official backports
either. Sometimes there is just enough time, or other circumstances.
This is not a problem with large enough pool of active maintainers.
> who removes
> packages when, who makes sure maintainers actually take care of what
> they upload?
I would assume that DDs are qualified enough to be trusted what they upload?
> how are bugs being reported?
IMHO all bugs should be reported to our bug tracking system.
> What about security issues?
Does not matter. Sometimes lack of security support is precisely the reason
why you want a package in fasttrack/backports.
For example, it is not uncommon for a package without meaningful security
support upstream (e.g. Oracle) to be marked as "unfit for release" (by a bug
with severity "serious"). Such packages will not migrate to "testing" and
therefore can not be introduced to backports.
Maintaining such packages only in "unstable" makes little sense if there is
no channel to provide them to users of current release.
I have misfortune of maintaining one such package: "mysql-workbench" and
because I don't run Sid on my desktop I have to maintain unofficial backport
anyway, just to be able to run the package. Hardly anyone can use a package
that exist only in "unstable" so no wonder that users asked me to backport
MySQL Workbench many times but I can not do that under current policy.
Another case could be almost the opposite -- when there is a security support
but only for a short time when release cycle is rapid. GitLab is one such
example, arguably not suitable for "stable" but necessary in fasttrack/
backports in order to be usable.
--
Cheers,
Dmitry Smirnov
---
Success consists of going from failure to failure without loss of enthusiasm.
-- Winston Churchill
signature.asc
Description: This is a digitally signed message part.
