Re: The role of the DPL in technical decisions

[Sven Luther <sven.luther@wanadoo.fr>]

On Wed, Mar 02, 2005 at 12:52:47PM +0000, Matthew Garrett wrote:
> 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.

Thanks for the reply, and i think your reply went beyond my question. I just
wanted to know about the NEW subset which concern packages that our policy or
common practice mandates a package renaming which automatically trigger NEW.

As i understand the NEW handling is needed for :

  a) make sure the licence is ok, and the package is otherwise distribuable,
  and maybe setup the US-big-brother survey of developer's work.

  b) check if the new package upload doesn't split in too many subpackages or
  whatever and doesn't explode the archive:

Friendly,

Sven Luther