FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 06-24-2012, 05:51 PM
Neil Williams
 
Default duplicates in the archive

On Sun, 24 Jun 2012 19:31:12 +0200
Arno Töll <arno@debian.org> wrote:

Dropping the bug CC.

> On 24.06.2012 19:15, Neil Williams wrote:
> > This bug is *not* useful to anyone. Please close it and find an
> > RC bug to close instead.
>
> I'm pretty sure this could be expressed in another tone. Especially
> since we welcome everyone (you know) and we have _no_ written rule what
> belongs into Debian and what not, and nobody who decides on that beyond
> legal issues.

This isn't about welcoming people, this is about keeping pointless
vanity packages out of the archive. We don't need absolute rules on
this but the whole point of ITP bugs being CC'd to this list is so that
people on this list get a chance to head off mistakes. Adding another
pointless alternative for packages which are already duplicated over
and over *is* a mistake.

Maybe the Developer Reference should be strengthened to require a check
against the existing archive as well as the WNPP list but, IMHO, that's
a bit of common sense which all maintainers and prospective maintainers
should be able to demonstrate. If you feel that's not common, feel free
to file a bug against the Developer Reference.

Whatever happens, there is no place for yet another duplicate of
packages which already have multiple duplicates in the archive.

There isn't even any point waiting for such packages to get RC bugs to
be able to remove them. Stop them getting in in the first place.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 06-24-2012, 06:38 PM
Wookey
 
Default duplicates in the archive

+++ Neil Williams [2012-06-24 18:51 +0100]:
> On Sun, 24 Jun 2012 19:31:12 +0200
> Arno Töll <arno@debian.org> wrote:
>
> Dropping the bug CC.
>
> > On 24.06.2012 19:15, Neil Williams wrote:
> > > This bug is *not* useful to anyone. Please close it and find an
> > > RC bug to close instead.
> >
> > I'm pretty sure this could be expressed in another tone. Especially
> > since we welcome everyone (you know) and we have _no_ written rule what
> > belongs into Debian and what not, and nobody who decides on that beyond
> > legal issues.
>
> This isn't about welcoming people, this is about keeping pointless
> vanity packages out of the archive.

Arno's point was that if you were clever you could do both.

It's possible to tell someone that packaing this particular thing is a
bad idea without being rude and superiour. If one does that they might
go away with the impression that Debian is a civilised place where
they'd like to help out, rather than a place full of people who are
usually right but arrogant with it.

Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120624183857.GO13768@stoneboat.aleph1.co.uk">htt p://lists.debian.org/20120624183857.GO13768@stoneboat.aleph1.co.uk
 
Old 06-24-2012, 06:42 PM
Arno Töll
 
Default duplicates in the archive

Hi,

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), 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?

> There isn't even any point waiting for such packages to get RC bugs to
> be able to remove them. Stop them getting in in the first place.

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. 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.

That's how we end up with 42 display manager. Complaining on the 43th is
not the way to go.


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?

--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
 
Old 06-24-2012, 06:45 PM
Bart Martens
 
Default duplicates in the archive

On Sun, Jun 24, 2012 at 06:51:47PM +0100, Neil Williams wrote:
> On Sun, 24 Jun 2012 19:31:12 +0200
> Arno Töll <arno@debian.org> wrote:
>
> Dropping the bug CC.
>
> > On 24.06.2012 19:15, Neil Williams wrote:
> > > This bug is *not* useful to anyone. Please close it and find an
> > > RC bug to close instead.
> >
> > I'm pretty sure this could be expressed in another tone. Especially
> > since we welcome everyone (you know) and we have _no_ written rule what
> > belongs into Debian and what not, and nobody who decides on that beyond
> > legal issues.
>
> This isn't about welcoming people, this is about keeping pointless
> vanity packages out of the archive. We don't need absolute rules on
> this but the whole point of ITP bugs being CC'd to this list is so that
> people on this list get a chance to head off mistakes. Adding another
> pointless alternative for packages which are already duplicated over
> and over *is* a mistake.
>
> Maybe the Developer Reference should be strengthened to require a check
> against the existing archive as well as the WNPP list but, IMHO, that's
> a bit of common sense which all maintainers and prospective maintainers
> should be able to demonstrate. If you feel that's not common, feel free
> to file a bug against the Developer Reference.
>
> Whatever happens, there is no place for yet another duplicate of
> packages which already have multiple duplicates in the archive.
>
> There isn't even any point waiting for such packages to get RC bugs to
> be able to remove them. Stop them getting in in the first place.

Hi Neil,

I agree with Arno about the tone.

I don't have a strong opinion on whether this package in particular should be
kept out of Debian. You may be right about this package in particular, no
idea.

About allowing new packages in Debian in general : On the one hand you have a
point that Debian should not collect any free software, but on the other hand I
think that it is OK to have multiple implementations of the same/similar
functionality in Debian, and over time the popcon stats may indicate that a
newer package wins over an older package. It is, in my opinion, not always
possible to judge the potential of a package before it has been in Debian for
some time. Having competing alternatives in Debian is OK, even good, in my
opinion.

Regards,

Bart Martens


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120624184554.GA22443@master.debian.org">http://lists.debian.org/20120624184554.GA22443@master.debian.org
 
Old 06-24-2012, 07:36 PM
Neil Williams
 
Default duplicates in the archive

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. That's 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.

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.

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.

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.

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.

> 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.

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.

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.

> 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.

> 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.

> 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.

An ITP is meant to be a bug in Debian - that Debian is missing some
functionality. It is perfectly acceptable to require that such
functionality can be implemented in a different way by working with a
package we already have. 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.

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.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 06-24-2012, 07:48 PM
Neil Williams
 
Default duplicates in the archive

On Sun, 24 Jun 2012 18:45:54 +0000
Bart Martens <bartm@debian.org> wrote:

> About allowing new packages in Debian in general : On the one hand you have a
> point that Debian should not collect any free software, but on the other hand I
> think that it is OK to have multiple implementations of the same/similar
> functionality in Debian, and over time the popcon stats may indicate that a
> newer package wins over an older package. It is, in my opinion, not always
> possible to judge the potential of a package before it has been in Debian for
> some time. Having competing alternatives in Debian is OK, even good, in my
> opinion.

The maintainer has to make that judgement, it's just one of the things
maintainers have to do. popcon is no indicator here, it is about
whether there is a bug in Debian, independent of this package. I apply
the same criteria to all my packages and I have and will continue to
remove any which do not merit a place in a stable release.

What *quality* issue is meant to being fixed by a new package? If
there's none, then the ITP is invalid and the package is without merit.
Just like any other bug - if the submitter has just got it wrong (for
whatever reason), the bug can be deemed invalid. Sometimes an
improvement to the documentation can help others not make the same
error, sometimes the docs are fine and it's just a mistake.

Multiple implementations hurt the archive, waste ftpmaster time, waste
QA time, waste wanna-build time, waste Debian resources, complicate
transitions and often collect RC bugs. In short, the more duplicates
there are, the higher the percentage of those duplicates which will
go to rot in the archive, causing aggravation for everyone.

Competition is useful, surfeit is harmful.

If a new package does have merit compared to all the existing
equivalents, then explain those merits and let your peers judge the
package.

The issue is to fix the problem in Debian, not just introduce a new
package which fixes nothing.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 06-24-2012, 08:21 PM
Josselin Mouette
 
Default duplicates in the archive

Le dimanche 24 juin 2012 ŕ 20:42 +0200, Arno Töll a écrit :
> What makes 42 window manager acceptable but not 43?

Who said 42 is acceptable?

--
.'`. Josselin Mouette
: :' :
`. `'
`-


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/1340569299.29283.0.camel@tomoyo
 
Old 06-24-2012, 08:46 PM
Bart Martens
 
Default duplicates in the archive

On Sun, Jun 24, 2012 at 08:48:48PM +0100, Neil Williams wrote:
> On Sun, 24 Jun 2012 18:45:54 +0000
> Bart Martens <bartm@debian.org> wrote:
>
> > About allowing new packages in Debian in general : On the one hand you have a
> > point that Debian should not collect any free software, but on the other hand I
> > think that it is OK to have multiple implementations of the same/similar
> > functionality in Debian, and over time the popcon stats may indicate that a
> > newer package wins over an older package. It is, in my opinion, not always
> > possible to judge the potential of a package before it has been in Debian for
> > some time. Having competing alternatives in Debian is OK, even good, in my
> > opinion.
>
> The maintainer has to make that judgement, it's just one of the things
> maintainers have to do. popcon is no indicator here, it is about
> whether there is a bug in Debian, independent of this package.

Not only the maintainer but also the many users judge how useful a package is
in Debian. This judgement cannot always be made at ITP time. Popcon does
indicate how popular the package is, doesn't it ?

> I apply
> the same criteria to all my packages and I have and will continue to
> remove any which do not merit a place in a stable release.

I see no problem with removing packages that don't belong in a Debian stable
release. But weren't we talking about judging at ITP time on whether the
package is allowed to enter Debian ?

>
> What *quality* issue is meant to being fixed by a new package? If
> there's none, then the ITP is invalid and the package is without merit.
> Just like any other bug - if the submitter has just got it wrong (for
> whatever reason), the bug can be deemed invalid. Sometimes an
> improvement to the documentation can help others not make the same
> error, sometimes the docs are fine and it's just a mistake.

I don't think that an ITP is only valid if it fixes something in Debian.
Sometimes a package is worth entering Debian simply because it is good free
software, regardless of any alternatives already in Debian.

>
> Multiple implementations hurt the archive, waste ftpmaster time, waste
> QA time, waste wanna-build time, waste Debian resources, complicate
> transitions and often collect RC bugs. In short, the more duplicates
> there are, the higher the percentage of those duplicates which will
> go to rot in the archive, causing aggravation for everyone.

I'm not convinced that the above applies to "multiple implementations" more
than to simply "many packages". Neglected packages about should be removed.
That applies to any package in Debian, not only to "multiple implementations".

>
> Competition is useful, surfeit is harmful.
>
> If a new package does have merit compared to all the existing
> equivalents, then explain those merits and let your peers judge the
> package.

If there are sufficient volunteers who want to spend their time on packaging
the software and maintaining it in Debian, then why not let the users judge the
package ?

>
> The issue is to fix the problem in Debian, not just introduce a new
> package which fixes nothing.

The issue is to allow new packages a chance in Debian to rise above the
existing alternatives in Debian. This cannot always be judged at ITP time.

Regards,

Bart Martens


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120624204655.GZ22443@master.debian.org">http://lists.debian.org/20120624204655.GZ22443@master.debian.org
 
Old 06-24-2012, 08:48 PM
Bart Martens
 
Default duplicates in the archive

On Sun, Jun 24, 2012 at 10:21:39PM +0200, Josselin Mouette wrote:
> Le dimanche 24 juin 2012 ŕ 20:42 +0200, Arno Töll a écrit :
> > What makes 42 window manager acceptable but not 43?
>
> Who said 42 is acceptable?

The neglected ones should be removed. If they're all well maintained and all
used, then 43 is acceptable, in my opinion.

Regards,

Bart Martens


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120624204843.GA22443@master.debian.org">http://lists.debian.org/20120624204843.GA22443@master.debian.org
 
Old 06-24-2012, 09:18 PM
Neil Williams
 
Default duplicates in the archive

On Sun, 24 Jun 2012 20:48:43 +0000
Bart Martens <bartm@debian.org> wrote:

> On Sun, Jun 24, 2012 at 10:21:39PM +0200, Josselin Mouette wrote:
> > Le dimanche 24 juin 2012 ŕ 20:42 +0200, Arno Töll a écrit :
> > > What makes 42 window manager acceptable but not 43?
> >
> > Who said 42 is acceptable?
>
> The neglected ones should be removed. If they're all well maintained and all
> used, then 43 is acceptable, in my opinion.

There is general agreement that neglected ones should be removed, it
just comes down to someone doing the work and making that assessment. If
you're interested, file the RM bugs in time for wheezy.

Feel free to re-use a similar measure/approximation for "neglect" as I
blogged about for the measure/approximation of "rubbish". (Linked from
my homepage below.)

With any objective analysis of the current 42, I find it impossible to
believe that all 42 would re-qualify.

Of course, someone who wanted to introduce #43 may be the person in
the right place to do the analysis.

It isn't a small task - if it doesn't get done for wheezy it's not that
bad but it does seem justified before #43 arrives. I'd expect that the
process itself shows that #43 isn't actually needed at all and that
whatever is desired can be achieved by patching one of the existing
ones.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 

Thread Tools




All times are GMT. The time now is 04:22 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org