The role of the DPL in technical decisions
Sven Luther <sven.luther@wanadoo.fr> wrote:
(following up here for now - I think it's a question that could do with
more discussion than IRC really allows for)
> I would like to know from the DPL candidates what is their opinion on way the
> ftp-masters handle the NEW queue, and in particular how they handle the
> packages that are not really NEW : renamed binary/source packages, package
> split, new kernel version and new library version which need a new package
> upload.
Speaking personally, it would certainly be nice if packages went through
NEW quicker. However, I don't think that's entirely relevant:
> Do you think there is currently a problem about this, and if so what do you
> intent to change in this regard.
Do I think there's a problem? Only in that people are unsure what causes
delays in NEW processing, and as a result are unable to form a good
opinion about whether those delays are acceptable or not.
Fundamentally, it isn't the DPLs job to make judgements about the
technical decisions a team makes. If the ftp-masters believe that the
current handling of the NEW queue is the best way of doing so, then
that's their decision to make. The developers have the right to
criticise that, and it would be nice if we could have a reasonable
discussion about whether it could be improved. In the end, if the
developers and the ftp-masters continue to disagree, we have the
technical committee to decide who's right.
Put simply, the constitution says that the DPL can't make technical
decisions that overrule other people. I agree with the constitution.
However, I will work to ensure that it's possible for people to find out
/why/ NEW is processed the way it is. Teams have the authority to make
technical decisions - they should be willing to justify them to the rest
of the project.
--
Matthew Garrett | mjg59-chiark.mail.debian.vote@srcf.ucam.org
Reply to: