Raphael Hertzog wrote: > Hi, > > On Fri, 09 Jan 2009, Russ Allbery wrote: >> I'm with Steve on this. I think the ftp team review is valuable, and as a >> project it takes us much more effort to deal with critically buggy >> packages after they're in the archive than before they get there. >> >> All of the teams who have to deal with critically buggy packages once >> they're in the archive are chronically understaffed. > > What are those teams? I can only think of the security team that has a > duty to support the security of the stable release. And even this team has > now some (widely unknown) way to say that they don't fully support some > specific packages (they do that with a specific tag in debtag).
There is the QA Team, the Release Teams and the Security Team at least. > And in the case of Qmail, the security team said that they have no > probleme supporting it. The code might be security supportable, but still not easy to integrate in a distribution nor have the quality expected to be in a release. I do think packages which don't qualify for inclusion in the release because of quality issues should be able to be uploaded to the archive, though only when there is a high chance that these quality issues (including integration issues) will be solved. >> If the packages aren't accepted in the first place, fixing the bugginess >> is the problem of the person who wants to upload them. After they're >> accepted into the archive, in practice dealing with it often becomes the >> problem of a lot of other people who have other critical tasks. >> Overall, I think an ftp team reject is a fairly good tradeoff unless >> they're frequently wrong, and I haven't gotten the impression that they >> are. > > Would it make sense to have an "unsupported" dist where packages can > not be auto-transitioned by the maintainer to sid ? We have experimental, though there is nothing in effect that prevents a maintainer to upload experimental packages to unstable atm... > So that we have a place for such packages without imposing any duty on > Debian as a whole and so that we leave a real chance for motivated > maintainer to enhance them within Debian. It would be a bit like the > "staging" area in the Linux kernel. Whatever staging area you have within Debian, it will be a suite so FTP Master will be involved and the QA Team would (should) make sure unspotted cruft gets noticed... Cheers Luk -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
