Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Luk Claes <luk@debian.org> writes:
> Raphael Hertzog wrote:
>> 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.
Yes. Plus anyone who looks at RC bugs, although if the package isn't in
testing, it gets filtered out of the more critical lists. There are also
the buildd maintainers and porters, depending on the nature of the bug.
Once a package makes it into Debian, we do a fairly good job at taking
collective responsbility for dealing with it. I think this is one of the
strengths of Debian, but it does mean that uploading a package is an act
that doesn't only affect the maintainer. It places some implicit demands
on other people's time as well.
> 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.
That sounds right to me too.
>> 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...
Packages only in experimental are ignored by Release and Security, so that
would address part of my concern. (And I expect QA to mostly ignore them
as well unless nothing appears to be happening with them.)
I like the idea mentioned earlier in this bug of using experimental as a
place to put a package with known issues while those issues are tracked as
a compromise. I think a reject is better as a general policy for most
packages, but for controversial cases, using experimental to see if the
bugs really will be fixed may be a good idea.
>> 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...
I think our collective responsibility for packages is a feature, not a
bug, so I'm not particularly thrilled by the idea of having an official
area in the project that doesn't imply some level of collective
responsibility. It's trivial to create a personal Debian repository, and
people already use that to distribute and test packages that shouldn't
place any obligations on the rest of Debian.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: