On Fri, 09 Jan 2009, Steve Langasek wrote: > There are three possibilities here: > > 1) The ftp team have a duty to judge whether a NEW package is too buggy to be > allowed into the archive. > 2) The ftp team may exclude NEW packages from the archive that they believe > are too buggy, but do not have an obligation to do so. > 3) The ftp team must not exclude NEW packages from the archive on the basis > that they consider them buggy. > > Which of these are you arguing holds?
2. I believe they don't have a duty to judge the quality but they have to take into account the input that all DD (and that includes ftpmasters themselves) might have left on the ITP bugs. They must weigh the arguments given and give some more importance to any reservation of the security team (and possibly release/qa team). > I have no doubt at all that it's 1), because it's plainly written in Policy > that packages in main "must not be so buggy that we refuse to support them", > and the ftp team are who controls whether a package is in main. As I told elsewhere, it's the people who have to do the support that should decide if they can do it, and not the ftpmasters. That means mostly the maintainer himself and the security team. > The ftp team reviews all new packages to determine whether they're suitable > for main, so that's not a special case. What's special is that the ftp team > can reach a decision of "too buggy" more easily because they have more > information available than they do about the average package. Would you > have the ftp team wear blinders and ignore all information they didn't learn > by inspecting the uploaded package? I don't think that's reasonable; I Of course no. I was just pointing out that if we consider it a duty of the ftpmasters to judge quality, then the treatment of qmail was unfair compared to all the other crap that got in without review. But as I'm not the one arguing that it's a duty, I don't have a problem with the unfairness if the process is clear and doesn't give the ftpmasters any special powers in the standard quality review process. (Yes my point of view is slowly evolving with the discussion) > > Given that the definition of crap will change from developers to > > developers, and until we have an agreed upon definition of crap, > > I don't think it's reasonable to expect the ftpmasters to filter > > out crap that some Debian developers want to maintain. > > Why not? If the maintainer disagrees, there's a procedure for resolving the > dispute - appeal to the TC. Whoever takes the decision, we still need an agreed upon definition of crap, otherwise people will be unhappy to not be able to maintain the piece of software they care about. Even if that software is crap. > But it's certainly not the case that developers have a *right* to have any > free software they choose to maintain accepted into the archive. Well, maybe it should. But that right could be limited to a sub-part of Debian called "unsupported". It's IMO important to leave a chance to each DD to use the Debian infrastructure (BTS/buildd) to improve software that they would like to see integrated in Debian. <digression: another reason for unsupported> For instance I maintain sql-ledger but it has no proper security support and it's "documented" in the README.Debian and the security team has documented it with the tags secteam::etch-limited-support and secteam::lenny-limited-support. Given this, I think that "main" is not the proper place for that software. But I need it, and I know others who rely on it and I want to continue to maintain it in Debian until a viable replacement is packaged. </digression> Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org