Re: list what's in the NEW queue?

["Marcelo E. Magallon" <mmagallo@debian.org>]

Hi,

 pardon me for the delay, I really have better things to do that getting
 involved all day long in discussions with purposely obtuse people.

On Fri, Feb 04, 2005 at 01:30:22PM +1000, Anthony Towns wrote:
 > Marcelo E. Magallon wrote:
 > >On Fri, Feb 04, 2005 at 11:21:02AM +1000, Anthony Towns wrote:
 > >
 > > > >On Thu, Feb 03, 2005 at 08:39:10PM +0100, Joerg Jaspert wrote:
 > > > > * it's not ftp-master's business to judge on _technical_ merits
 > > > >   of the pacakge (bad packaging practices, missing
 > > > >   dependencies, ignores /chapter and verse/ of policy, ...), so
 > > > >   we can safely rule that one out
 > > > Uh, wtf are you on?
 > > Anthony, please, think in context.  Use some common sense.
 > 
 > Ah, arrogance and self-righteousness with a dash of utter ignorance.
 > Fair enough.

 And there goes your typical MO on mailing lists _again_.

 Shall I remind you that *you* are the one that recently put a request
 for more civil and productive discussions down in written form in front
 of the whole project?  Please, by all means, do as you say.  I'll be
 delighted to follow suit.

 > > Or is it now your intention to burden the bunch of people who
 > > actually do some work as ftp-master with package nitpicking, too?
 > > Give me a break.
 > 
 > Dude, you have no idea what you're talking about.

 Maybe, I sit on the wrong side of ftp-master, it's been always like
 that and I have no intention whatsoever to change that because I'm not
 afraid to admit that I don't have the resources to volunteer for such a
 task.

 That doesn't make my own appreciation of the situation wrong.

 > Processing of NEW packages is done with a tool called "lisa", the use
 > of which involves two steps -- checking the package, then either
 > accepting it, rejecting it, or skipping it. Checking it invokes a
 > library called "fernanda.py" whose _sole_ purpose is finding
 > technical issues with the package; it runs both lintian and linda,
 > gives a full manifest of the changed packages, lists the contents of
 > the control file, highlighting issues that might need attention,
 > dumps the copyright file, and so on.

 Pretty tale.

 Useless, too.

 A certain truly new, not previously on the archive, package with
 *obvious* technical flaws recently sat on NEW for a period a bit shy of
 two weeks, and after this time certainly devoted to careful scrutiny it
 just made its way into unstable.  The problem here is that the flaws
 are obvious to anyone with a clue about the package, which I simply
 won't require ftp-master to have because it is not their task nor
 place.

 In the meantime, there's plenty of packages _already_ in the archive
 which were split, reorganized or simply added new components, either
 because upstream includes more stuff, a bug requires this action to be
 taken, policy requires this action or the maintainer simply realized
 that -- in three years time, or whenever sarge+1 actually releases
 unless something changes drastically in this project -- there will be a
 better upgrade path in that way.

 What you are saying reads to me as if stuff that already in the archive
 gets more attention and demands more time than stuff that's plain new.

 The situation wouldn't be this bad if all these "issues that need
 attention" would end up in the developer's mailbox and a public mailing
 list.  But since ftp-master take the actions you mention and says
 *nothing* to the involved parties (which in this case happen to be "the
 whole project").  I can't honestly image that there's no communication
 among ftp-master members: "I'm looking at that", "I don't like that",
 "that gives me the willies", ... because you have to _somehow_ avoid
 stepping on each other's toes.

 Now, *please*, shed some your wisdom and knowledge on me once again and
 do tell me where's the problem with sharing this data with the rest of
 the project.

 And just to save you some detective work: yes, there's a package of
 mine sitting in NEW, it's mesa.  It's been there for over two months.
 I'd be complaining the same if it wasn't there because this has
 happened before and it has happened in other areas of the project,
 perhaps most notably with the new maintainer queue and the keyring.

 > > Let me use a package of mine as an example: mesa 6.2.1-1 (source)
 > > produces, among others, the binary package mesag3.  This package
 > > ships libGL.so.1.  This is a violation of 8.1 ("The run-time shared
 > > library needs to be placed in a package called
 > > `<libraryname><soversion>' [...]").
 > 
 > *shrug* The proper thing to do when policy recommends something
 > that's wrong is to fix policy. That policy isn't particularly well
 > maintained has very little to do with whether NEW packages will have
 > their technical flaws examined or not.

 There is simply no way to bend policy to accommodate this case.  The
 name "mesag3" is historic and fooling with transitional packages to get
 it "fixed" is pointless.  A mistake was made, really really long ago,
 and that mistake has propagated up to the point where it causes more
 harm that good to fix it.

-- 
Marcelo