Re: list what's in the NEW queue?
- To: email@example.com
- Subject: Re: list what's in the NEW queue?
- From: "Marcelo E. Magallon" <firstname.lastname@example.org>
- Date: Sun, 6 Mar 2005 09:16:47 -0600
- Message-id: <[🔎] 20050306151647.GA8107@jacinta.casa>
- Mail-followup-to: "Marcelo E. Magallon" <email@example.com>, firstname.lastname@example.org
- In-reply-to: <4202EC4E.email@example.com>
- References: <firstname.lastname@example.org> <20050203134554.GM4721@mauritius.dodds.net> <20050203145504.GA7306@poczta.o2.pl> <email@example.com> <firstname.lastname@example.org> <email@example.com> <20050204000304.GA9847@jacinta.casa> <4202CDFE.firstname.lastname@example.org> <20050204023847.GA11527@jacinta.casa> <4202EC4E.email@example.com>
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
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.
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
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
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.