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
Description: This is a digitally signed message part.