[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DPL election IRC Debate - question about the NEW handling.



On Wed, Mar 02, 2005 at 07:41:09PM -0800, Anthony Towns wrote:
> Sven Luther wrote:
> >On Mon, Feb 28, 2005 at 09:29:41AM +0000, Helen Faulkner wrote:
> >>You are welcome to either post suggested questions to this list, or to
> >>email myself and/or Martin privately with your suggestions.  If you wish
> >>your questions to be anonymous, please email us privately and make that
> >>clear.
> >Ok, i have one question.
> 
> Can we keep the debate questions off this list? Otherwise the choice is 
> between leaving them unanswered for a couple of weeks until the debate, 
> or having them already answered on the list, and thus redundant for the 
> debate. Having different Subjects for different topics would be nice too...

I don't know, maybe email debate is better, it allows for more in depth
discussion.

> >I would like to know from the DPL candidates what is their opinion on way 
> >the
> >ftp-masters handle the NEW queue,
> 
> I think this is the wrong question. The right question to ask is what 
> the ftpmasters think of the way NEW is being handled, and what resources 
> they would appreciate. There's two reasons for this. One is the whole 
> point of having people running a particular area is that they know 
> what's going on; given the choice between a specialist's analysis of the 
> problems and a generalist's, take the former. The other is that asking 
> the DPL or DPL candidates to look for problems in the way others are 
> doing their jobs is just asking for unnecessary conflicts: there are 
> _always_ going to be problems in the way _every_ task within Debian is 
> handled. The issue isn't whether there are problems, it's which problems 
>  are the most important to handle. And NEW processing doesn't even come 
> close.

Well, the current status of it is somewhat discouraging for the developers, if
not more. So i think i somehow have to disagree with that. And it ties in
directly to the fact that ftp-master mailing list is a black-hole.

> >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. 
> 
> NEW is a technical term -- it means binary and source packages that are 
> not already in the archive under that name. So those packages *are* 
> really NEW, and that's not even a debatable question. I've already 
> addressed this topic with my ftpmaster hat on recently, see:
> 
>   http://lists.debian.org/debian-project/2005/02/msg00225.html

Mmm, wasn't aware of this one.

But now, the question is the following : Do a 2.6.11 kernel package, which is
exactly the same as the 2.6.10 kernel package except there was a new version,
really need 2 possibly lengthy NEW delays ? It will happen in a previsible way
for each new upstream version showing up, and don't really need any review.
The same would go for soname-changes in shared libraries.

Would not some wildcarding in the override file solve this easily, and at the
same time diminish the amount of work needed to handle those by the
ftp-masters ? 

> >Do you think there is currently a problem about this, and if so what do you
> >intent to change in this regard.
> 
> What I am doing about it is processing packages that are stuck in NEW 
> that are holding up higher priority tasks such as the release and 
> security updates. Other ftpmasters are doing likewise.

Or those that some privilegied subgroup mention to you on irc :)

> What I will do if elected is to support ftpmaster and other delegates in 
> their actions so they can focus on doing useful work according to their 
> own best judgement (which is, after all, why they're a delegate in the 
> first place), rather than having to justify their actions in response to 
> the latest fad complaint.

Notice that i have been complaining about NEW since over a couple of years
now. having packages sitting in NEW for > 1 month for just a minor detail
which could as well be automated is not acceptable.

Friendly,

Sven Luther



Reply to: