On Wed, Mar 02, 2005 at 12:52:47PM +0000, Matthew Garrett wrote: > Sven Luther <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
