Re: duplicates in the archive
On Sun, Jun 24, 2012 at 08:36:13PM +0100, Neil Williams wrote:
> On Sun, 24 Jun 2012 20:42:33 +0200
> Arno Töll <arno@debian.org> wrote:
>
> > On 24.06.2012 19:51, Neil Williams wrote:
> > > Whatever happens, there is no place for yet another duplicate of
> > > packages which already have multiple duplicates in the archive.
> >
> > Letting alone the package in particular (I don't even know it, nor do I
> > care)
>
> (Neither do I, particularly - but Thomas' list made it just too
> obvious that there was no justification for the bug report at the time
> of filing.)
>
> >, I wonder where you'd draw that line. As you say yourself: There
> > are lots of alternative packages in the archive already. So, what makes
> > all the other alternatives acceptable but this one not?
> >
> > What makes 42 window manager acceptable but not 43?
>
> If it can be justified. That's what the objective comparison would need
> to demonstrate.
The rejection of #43 should be justified, for example with conclusions from
such comparison with the 42 other implementations.
> That's an established pattern in Debian -
Let's not call your personal view "an established pattern in Debian". Let's
debate this and find a consensus before documenting it and advertising it as
"an established pattern in Debian".
> if someone
> wants to add something which is the same as something else, there
> should be a good reason to introduce the new one in that it needs to be
> better than the existing ones in some way which isn't achievable just
> by patching one of the existing ones.
It is, in my opinion, OK that someone expresses an intent to package a 43th
implementation in public so that anyone can compare it with the 42 other
implementations and then argue why #43 would not be needed in Debian.
>
> Debian works on merit - packages and maintainers. Suggesting or
> packaging something which is without merit will usually result in
> complaints from your peers. Cope with it. Maintainers should not expect
> to be treated with kid gloves when what they are actually doing is
> wasting the free time of other volunteers.
You can prevent your free time from being wasted by ignoring this ITP. If you
actively want to keep the package of this ITP out of Debian, then you should
produce some reasonable arguments, maybe after comparing all 43
implementations. But then it's your choice for doing all that work. Please
don't blame the ITP submitter for wasting your time.
>
> We're used to 'Justification' as a concept for RC bugs, well an ITP is
> a bug in Debian and can also require justification. Some ITP bugs are
> simply invalid.
An ITP is an expression of an intent to package some software. It does by
itself not express "I have analysed every alternative in Debian and I think
this one is better". If you feel that this one is not better, then you should
justify the rejection of the ITP.
>
> Someone needs to make that call and as we're all part of the QA team,
> various people do it according to their own free time, work area,
> expertise and general levels of annoyance with daft ideas.
Yes, anyone can justify why an ITP should be rejected.
>
> Whether it's a joke package or a tiny package which needs to go into a
> collective package (goodies or devscripts or whatever), if maintainers
> (prospective or existing) can't do their own research ahead of filing a
> bug, it is up to the rest of us to point out the error.
Yes, you're right about this. That's what I understand in "peer review".
>
> > I'm not in favor to get yet another window manager in Debian. All I'm
> > saying is that filing a WNPP bug and wait whether a people complain loud
> > enough is not the way to learn that.
I think that it is OK that other people complain about an ITP. It is also OK
to be very clear about why an ITP in particular is not welcome. Of course,
politeness and friendliness are generally appreciated, and I think that this
aspect started the debate.
>
> So feel free to file a patch to the Developer Reference explaining that
> if maintainers of prospective packages don't check for existing packages
> which provide the same or very similar functionality, any request to
> package such a duplicate needs to be accompanied by a detailed
> reasoning of *why* the existing packages are sufficiently inadequate
> that a new package is warranted instead of patching what we have.
If you feel that Developer Reference can be improved, then feel free to do
suggestions. The above is not a suggestion I can support.
>
> To me, such an expectation is common sense and I'm quite happy to
> continue criticising ITP's on the basis of being an unjustifiable
> duplicate of existing packages.
It is good that you continue reviewing ITPs. But I would appreciate (and the
ITP submitter would probably also appreciate) that you justify rejecting ITPs
with good arguments and in a friendly way.
>
> > Especially since a WNPP bug
> > complaints are not worth that much. If you happen to find a DD to upload
> > your stuff or you are DD yourself, you can silently ignore any comments
> > if you like and upload nonetheless.
>
> At which point, the credibility of any such DD is diminished, as is
> the credibility of any DD who sponsors such packages despite
> complaints from his/her peers.
Yes, credibility and reputation are affected by uploads. Also by how one
rejects ITPs.
>
> > That's how we end up with 42 display manager. Complaining on the 43th is
> > not the way to go.
>
> The 43rd must be *justified* - there needs to be a reason why the lack
> of this package is a bug in Debian. Otherwise the request could just as
> well be reassigned as a wishlist bug against one of the alternatives.
Anyone is free to justify the rejection of #43 with good arguments.
>
> > Moreover, would you be a well respected Debian Developer today if your
> > replies to your first WNPP bug (if you filed any, I don't know) back
> > then told you to go away, nobody appreciates your work?
>
> As hinted in my previous post, I did my research before filing my first
> (and subsequent) ITP bugs. Nobody disagreed at the time and I have
> since removed the first package I introduced into Debian as it's time
> had passed. There were no duplicates but there was also no
> justification for it remaining in the archive for wheezy.
That sounds like you're doing good work on that.
>
> An ITP is meant to be a bug in Debian - that Debian is missing some
> functionality.
Or that the ITP submitter feels that the software is worth to be in Debian.
> It is perfectly acceptable to require that such
> functionality can be implemented in a different way by working with a
> package we already have.
Anyone can do the analysis of comparing alternatives already in Debian.
> Triaging bugs requires that the bugs are
> tested for validity before spending more time on the fix. No point
> putting the wrong fix into the archive.
True.
>
> However, I also had comments from other bugs once becoming a DD which
> showed where I'd gone wrong on those packages, but that just meant that
> I had to show I could accept criticism and just get on with fixing
> stuff. Those who did criticise me I now count as friends, so that is
> how I think Debian should work.
It is a good quality, in my opinion, to be able to accept criticism.
Regards,
Bart Martens
Reply to: