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, 09:51 PM
Neil Williams
 
Default duplicates in the archive

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

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

Popcon indicates almost nothing - least of all popularity. The
weaknesses of popcon for archive-related questions is well documented.
It might give a hint but it is *not* a reliable indicator.

99% of the Debian machines I install have no means of communicating via
popcon - ever. What's installed on those is completely invisible.

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

Yes. An ITP is a bug in Debian and bugs need to be triaged - triage
involves assessing whether the bug is valid. Before trying to fix the
problem, identify that the problem is the problem you think it is.

That kind of response makes me think that you haven't tried to remove a
set of packages and have no idea how difficult it can be.

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

Rubbish. Complete tosh. That is precisely the attitude that leads to
Debian being seen as a dumping ground for vanity packages and other
trash.

An ITP is a statement that there is some *functionality* absent in
Debian. Someone cannot do something because the existing packages don't
provide that functionality - that is a justification for a new package
but it can also be justification for a patch to an existing package.
Copying ITP bugs to this list is one of the ways of spotting when that
can be done instead of adding another package.

If I file a bug against one of your packages that it needs to do
something which would be a complete waste of your time, do you not
have the right and obligation to tell me to not be so stupid and to
close the bug as invalid? Well, WNPP is one of your packages just as it
is one of mine because it comes under the QA team.

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

Yes, so do both. There are still plenty of packages which could
justifiably be removed before Wheezy is released.

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

There never *ARE* enough volunteers. Even if there are today, there is
no guarantee that there will be by the time of the next release and
when volunteers give up, they tend not to have time to tidy up after
themselves by removing packages.

Why do you think we have so many RC bugs? We never have enough
volunteers - if we did, we could have frozen at the start of June and
we would make the release on the last day of DebConf.

As it is, we have over 670 RC bugs right now and we only have one Gregor
Herrmann.

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

On what basis are things going to "rise above" if there is nothing which
separates them from the existing packages?

NotInventedHere syndrome should *not* be welcome in Debian. That's not
progress, that's just abusing the contributions of your peers.

Don't make more work for people.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 06-24-2012, 09:58 PM
Adam Borowski
 
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?

Sure, let's start removals with ones that hard-depend on things a window
manager shouldn't touch, like network-manager. If one has to choose
between working networking and a given window manager, the choice is obvious
-- except maybe for newbie users, who won't understand what to do when they
get hard-stumped faced with a basic task like connecting a phone via USB[1],
or for less newbie ones, any bridged or multi-homed setup.

So, a good deal of smaller window managers are functionally redundant and
could be culled, but they at least don't break unrelated packages. Whether
one prefers Gnome3 interface or something more traditional[2] is one thing,
but there are technical downsides for Gnome that could be trivially fixed.
And yet are not.


[1]. With non-ancient udev, connecting one spawns an "usb0" interface you can
configure any usual way, unless you have n-m continuously screwing with it.

[2]. Let's not go into flamewars about user interface here, it has been
overdone already.

--
I was born an ugly, dumb and work-loving child, then an evil midwife
replaced me in the crib.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120624215814.GA32267@angband.pl">http://lists.debian.org/20120624215814.GA32267@angband.pl
 
Old 06-25-2012, 06:19 AM
Antti-Juhani Kaijanaho
 
Default duplicates in the archive

Adam Borowski <kilobyte@angband.pl> kirjoitti:

>Sure, let's start removals with ones that hard-depend on things a
>window
>manager shouldn't touch, like network-manager.

Which wm does that? I know it isn't gnome-shell at least, as I've been
using it quite successfully without nm installed.

(I hope this message looks okay - I'm sending from an unfamiliar
MUA.)
--
Antti-Juhani


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1eb44713-6893-4e9d-9cb5-9fd07e0c5d4c@email.android.com">http://lists.debian.org/1eb44713-6893-4e9d-9cb5-9fd07e0c5d4c@email.android.com
 
Old 06-25-2012, 06:24 AM
Bart Martens
 
Default duplicates in the archive

On Sun, Jun 24, 2012 at 10:18:00PM +0100, Neil Williams wrote:
> 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.

True.

> If
> you're interested, file the RM bugs in time for wheezy.

You question those 42 implementations, so you can analyse them, file RM bugs
where appropriate, and write a justification for rejecting #43.

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

If that text reflects consensus, then feel free to make
http://qa.debian.org/howto-remove.html point to that text.

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

Good, you seem to have already started with analysing those 42 implementations.

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

This person "may be in the right place to do the analysis", but I don't think
that this person must do that analysis.

>
> It isn't a small task - if it doesn't get done for wheezy it's not that
> bad but

The coming freeze period may be a good time for spending time on removals by
anyone interested.

> it does seem justified before #43 arrives.

It is not bad/wrong that you want that analysis to be done now.

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

Yes, the analysis may result in the conclusion that #43 is not needed in
Debian. But please don't reject #43 just because nobody (not you, not the ITP
submitter, not any volunteer) has compared it with the 42 other
implementations.

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: 20120625062421.GB17194@master.debian.org">http://lists.debian.org/20120625062421.GB17194@master.debian.org
 
Old 06-25-2012, 06:40 AM
Russ Allbery
 
Default duplicates in the archive

Neil Williams <codehelp@debian.org> writes:

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

I think it's hard to defend the contention that the quantity of packages
has some strong relationship to whether or not those programs duplicate
the functionality of other programs. Surely it also depends on the type
of program, rather heavily.

For example, I'm sure that we have more than 42 different programming
languages in the archive, so obviously we don't need Java, right? You can
do all the same things in C++. Or hey, let's pick one of either Perl or
Python; they can both do the same things.

I can definitely come up with more than 42 different ways to write an
editor, all of which may appeal to different people, different tasks, or
different work styles. But hey, I like Emacs, which clearly does
everything that vi can do, so away with vim! And nvi just duplicates vim!

We probably don't need 42 different ways to find duplicate files on local
disk, since that's a relatively clear and well-defined task and there's
only so many ways to go about it (and each implementation could probably
gain the features of the others). But window managers are fundamental to
one's style of interaction with the computer, and there are *huge*
differences between them. A tiling window manager is not interchangeable
with a desktop environment, which in turn is not interchangeable with a
window manager designed to be operated without a mouse, or one that's
optimized for a particular class of accessibility issues. And that's not
even getting into the window managers that are used primarily because they
embed a particular scripting language that people want to use to automate
their windowing actions.

By all means, let's get rid of packages that really do only offer subsets
of functionality of other packages. But UI is part of functionality, and
a different UI *is* a different feature. By all means, let's get rid of
poorly-maintained packages. But if someone finds a package that does
something in a way that nothing else does and that fits them, and they're
able and willing to take care of it, having a place for those is one of
Debian's strengths. We should be improving our tools and management
techniques for handling large numbers of packages, including for retiring
them when they're not being maintained, not trying to reduce the variety
and depth of the distribution.

And as sympathetic as I am to the concern about RC bugs in packages that
are already in the archive, I suspect it's rather rare that fixing random
RC bugs in other people's packages is the compelling, fun thing that gets
someone involved in doing Debian development. I know it happens, but I
bet more people join the project the way that I did: there's some specific
piece of software that they want packaged for the distribution they
already use, so they package it, and from that learn how to package, and
from that branch out into helping with other parts of the distribution.

Getting one's own package into the distribution is a really awesome
feeling. I don't think it's good for the growth of the project, or for
attracting new contributors, to put too many roadblocks in the way of
someone feeling that.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k3yvgai6.fsf@windlord.stanford.edu">http://lists.debian.org/87k3yvgai6.fsf@windlord.stanford.edu
 
Old 06-25-2012, 07:05 AM
Bart Martens
 
Default 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120625070555.GC17194@master.debian.org">http://lists.debian.org/20120625070555.GC17194@master.debian.org
 
Old 06-25-2012, 10:37 AM
Andrew Shadura
 
Default duplicates in the archive

Hello,

On Sun, 24 Jun 2012 20:36:13 +0100
Neil Williams <codehelp@debian.org> wrote:

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

It is definitely not the same and not duplicate. Different window
managers look differently and feel a lot differently (I thought it
should be obvious enough, isn't it?).

More to say, I'd like to see this window manager in Debian, jugding
by its documentation it seems to be really great, flexible yet tiny and
easily configurable, so I support it's inclusion fully.

--
WBR, Andrew
 
Old 06-25-2012, 10:38 AM
Svante Signell
 
Default duplicates in the archive

On Mon, 2012-06-25 at 08:19 +0200, Antti-Juhani Kaijanaho wrote:
>
> Adam Borowski <kilobyte@angband.pl> kirjoitti:
>
> >Sure, let's start removals with ones that hard-depend on things a
> >window
> >manager shouldn't touch, like network-manager.

Yes, why not!

> Which wm does that? I know it isn't gnome-shell at least, as I've been
> using it quite successfully without nm installed.

Have you tried to use evolution without NM?



--
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/1340620722.5945.3.camel@x60
 
Old 06-25-2012, 11:32 AM
Tollef Fog Heen
 
Default duplicates in the archive

]] Neil Williams

> Popcon indicates almost nothing - least of all popularity. The
> weaknesses of popcon for archive-related questions is well documented.
> It might give a hint but it is *not* a reliable indicator.

While it's not perfect, I'm not aware of any better tool we have.
Relying on hearsay about what people install is worse.

> 99% of the Debian machines I install have no means of communicating via
> popcon - ever. What's installed on those is completely invisible.

It does not matter how many machines are installed without popcon as
long as it is installed on a representative sample. Whether that is the
case is open for debate, but unless and until somebody comes up with a
better tool and method than using popcon, that's what we have.

[...]

> Rubbish. Complete tosh.

You might want to reconsider your choice of words. You're coming across
as quite hostile in this thread.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87bok7zkxw.fsf@qurzaw.varnish-software.com">http://lists.debian.org/87bok7zkxw.fsf@qurzaw.varnish-software.com
 
Old 06-25-2012, 12:49 PM
Antti-Juhani Kaijanaho
 
Default duplicates in the archive

Svante Signell <svante.signell@telia.com> kirjoitti:

>On Mon, 2012-06-25 at 08:19 +0200, Antti-Juhani Kaijanaho wrote:
>> Which wm does that? I know it isn't gnome-shell at least, as I've
>been
>> using it quite successfully without nm installed.
>
>Have you tried to use evolution without NM?

Evolution is not, so far as I know, a window manager. And no,
I have never used it, with or without NM.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 8953d159-a56b-4756-8b12-383af507eec1@email.android.com">http://lists.debian.org/8953d159-a56b-4756-8b12-383af507eec1@email.android.com
 

Thread Tools




All times are GMT. The time now is 09:33 AM.

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