main discussion list for development topics

Guus Sliepen | 28 Jun 2012 16:42

Improving our response to "duplicate" packages in Debian

Hello,

I believe our current way of responding to ITPs for software that duplicates
the functionality other software that is already in Debian is wrong. We have a
very lengthy discussion everytime such an ITP happen, but usually they change
nothing (the submitter just goes ahead with packaging it) or worse, they scare
away the maintainer along with his/her ITP.

The worst part is that when we say "but we already have N frobnicators in
Debian, we don't need an N+1th", we imply that the N pre-existing packages are
OK but that this new package is Very Bad just because it came late to the game. 

In fact, the fact that there is an ITP usually means that there is interest in
the software, that there is an active downstream maintainer, and usually both
these things would not be without an active upstream. The same may not be true
for some similar software package that has been in Debian for several years.

So, I propose our code of conduct when responding to "duplicate software" ITPs
should be:

- Don't immediately start complaining to the submitter of the ITP. Just let
  the submitter devote his/her energy to packaging.

  Some valid reasons to do complain immediately:

  - The software is very immature (version 0.1-alpha or something like that).
  - It's a simple script or very small program, and should be merged (either
    upstream or downstream) with another package.
  - It really is an exact duplicate or a fork of another package with almost no
    changes to the original.

(Continue reading)

headers

Axel Beckert | 28 Jun 2012 18:04

Re: Improving our response to "duplicate" packages in Debian

Hi Guus!

Guus Sliepen wrote:
> I believe our current way of responding to ITPs for software that duplicates
> the functionality other software that is already in Debian is wrong.
>
> The worst part is that when we say "but we already have N frobnicators in
> Debian, we don't need an N+1th", we imply that the N pre-existing packages are
> OK but that this new package is Very Bad just because it came late to the game. 

Thanks for summarizing the problem so nicely without getting
emotional. Now I don't have to send my flame on those "we don't need
an N+1th WM" guys for the wmfs ITP. 

> - Don't immediately start complaining to the submitter of the ITP. Just let
>   the submitter devote his/her energy to packaging.

Very important and usually the primary fail.

>   Some valid reasons to do complain immediately:
> 
>   - The software is very immature (version 0.1-alpha or something like that).
>   - It's a simple script or very small program, and should be merged (either
>     upstream or downstream) with another package.
>   - It really is an exact duplicate or a fork of another package with almost no
>     changes to the original.

Thanks for this list!

> - Research how many similar software packages are there actually in

(Continue reading)

headers

Jon Dowland | 28 Jun 2012 18:06

Re: Improving our response to "duplicate" packages in Debian

I really like these suggestions.

headers

Ben Finney | 29 Jun 2012 03:24

Re: Improving our response to "duplicate" packages in Debian

Guus Sliepen <guus <at> debian.org> writes:

> So, I propose our code of conduct when responding to "duplicate
> software" ITPs should be:
>
> - Don't immediately start complaining to the submitter of the ITP. Just let
>   the submitter devote his/her energy to packaging.

It's part of the job of a (prospective) package maintainer to advocate
for the package. That entails knowing how it compares to rivals for the
same function.

> - Research how many similar software packages are there actually in Debian

So this effort is the responsibility primarily of the person(s)
packaging the proposed work. Requests that they do that research are,
IMO, quite reasonable and should come as early as possible in the
process.

> - Go to the root of the problem: find out why upstream thinks they need to
>   write their software.

Again, contacting the upstream is a large part of the job of the package
maintainer.

This code of conduct you lay out is asking others to take responsibility
From the shoulders of the very people who, IMO, should have that
responsibility.

--

--

(Continue reading)

headers

Bart Martens | 29 Jun 2012 07:20

Re: Improving our response to "duplicate" packages in Debian

On Fri, Jun 29, 2012 at 11:24:44AM +1000, Ben Finney wrote:
> Guus Sliepen <guus <at> debian.org> writes:
> 
> > So, I propose our code of conduct when responding to "duplicate
> > software" ITPs should be:
> >
> > - Don't immediately start complaining to the submitter of the ITP. Just let
> >   the submitter devote his/her energy to packaging.
> 
> It's part of the job of a (prospective) package maintainer to advocate
> for the package. That entails knowing how it compares to rivals for the
> same function.

It is, in my opinion, OK that an ITP is submitted before the packages already
in Debian are studied.  And it is, in my opinion, also OK that anyone compares
the alternatives and comments on the ITP.

> 
> > - Research how many similar software packages are there actually in Debian
> 
> So this effort is the responsibility primarily of the person(s)
> packaging the proposed work.

I agree with Guus Sliepen on this.

> Requests that they do that research are,
> IMO, quite reasonable and should come as early as possible in the
> process.

I agree with "as early as possible in the process".  I think that anyone can do

(Continue reading)

headers

Holger Levsen | 29 Jun 2012 08:55

Re: Improving our response to "duplicate" packages in Debian

On Donnerstag, 28. Juni 2012, Ben Finney wrote:
> It's part of the job of a (prospective) package maintainer to advocate
> for the package. 

what???

if thats true, I don't want any of my package maintainance jobs. can you 
please fire me?

headers

Peter Samuelson | 29 Jun 2012 10:10

Re: Improving our response to "duplicate" packages in Debian


[Holger Levsen]
> if thats true, I don't want any of my package maintainance jobs. can
> you please fire me?

You've been around awhile.  If that is true, you should know how to RFA
or orphan packages and/or retire from the Project.  You should know by
now that it isn't up to others to "fire" you.

headers

Roger Leigh | 29 Jun 2012 10:49

Re: Improving our response to "duplicate" packages in Debian

On Fri, Jun 29, 2012 at 12:55:15AM -0600, Holger Levsen wrote:
> On Donnerstag, 28. Juni 2012, Ben Finney wrote:
> > It's part of the job of a (prospective) package maintainer to advocate
> > for the package. 
> 
> what???

I don't see anything unreasonable about being able to articulate the
reasons why a package should be part of Debian.  I don't mean having
to suffer a drawn out argument, but just being able to give the
reasons why it's important for the software to be in Debian, what
it does, and why it's sufficiently different from what we already
have.

Regards,
Roger

--

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

headers

Yaroslav Halchenko | 29 Jun 2012 18:18

Re: Improving our response to "duplicate" packages in Debian

I would go even 1 step further and seek from a perspective maintainer,
especially a non-DD/DM, at least some assurance that it is not a
fire-and-forget project for him (e.g. that he is using it extensively
and planing to do so for the next X years) and that he is willing
to put effort in proper maintenance of the package.  ITP -> 1 upload ->
X NMUs -> O is not that uncommon.  IMHO if there is a strong personal
motivation (i.e. active user) to get a package packaged, it might
provide additional weight toward "accepting" the package to be part of
Debian even if comparable alternatives exist.

I wonder if we shouldn't seek extending an 

/usr/share/pyshared/reportbug/debbugs.py:521:itp_template = textwrap.dedent(u"""\

with some advocation/motivation fields to make our discussion (upon
reaching the consensus if such could be reached) any fruitful ?

On Fri, 29 Jun 2012, Roger Leigh wrote:
> > > It's part of the job of a (prospective) package maintainer to advocate
> > > for the package. 

> > what???

> I don't see anything unreasonable about being able to articulate the
> reasons why a package should be part of Debian.  I don't mean having
> to suffer a drawn out argument, but just being able to give the
> reasons why it's important for the software to be in Debian, what
> it does, and why it's sufficiently different from what we already
> have.

(Continue reading)

headers

Philipp Kern | 1 Jul 2012 16:10

Re: Improving our response to "duplicate" packages in Debian

On Fri, Jun 29, 2012 at 12:18:49PM -0400, Yaroslav Halchenko wrote:
> I would go even 1 step further and seek from a perspective maintainer,
> especially a non-DD/DM, at least some assurance that it is not a
> fire-and-forget project for him (e.g. that he is using it extensively
> and planing to do so for the next X years) and that he is willing
> to put effort in proper maintenance of the package.  ITP -> 1 upload ->
> X NMUs -> O is not that uncommon.  IMHO if there is a strong personal
> motivation (i.e. active user) to get a package packaged, it might
> provide additional weight toward "accepting" the package to be part of
> Debian even if comparable alternatives exist.

Sadly even if you might be an active user in the beginning you might leave the
organization where you needed it.  Strong personal motivation helps pretty
much, but if you lose the environment, you might suddenly lack it completely.

Kind regards
Philipp Kern

headers

Yaroslav Halchenko | 29 Jun 2012 04:51

Re: Improving our response to "duplicate" packages in Debian

> - Research how many similar software packages are there actually in Debian, in
>   what shape they are, whether they have active upstream and downstream
>   maintainers. Complain about the worst package in that selection instead.

to address Ben's comments and to possibly distill Guus's nice list into
easily available and digestible post, I have placed an extract of
it into http://wiki.debian.org/ITP  so we could refine it and possibly
refer to it.

Cheers
--

-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

headers

Bart Martens | 29 Jun 2012 07:28

Re: Improving our response to "duplicate" packages in Debian

On Thu, Jun 28, 2012 at 10:51:53PM -0400, Yaroslav Halchenko wrote:
> > - Research how many similar software packages are there actually in Debian, in
> >   what shape they are, whether they have active upstream and downstream
> >   maintainers. Complain about the worst package in that selection instead.
> 
> to address Ben's comments and to possibly distill Guus's nice list into
> easily available and digestible post, I have placed an extract of
> it into http://wiki.debian.org/ITP  so we could refine it and possibly
> refer to it.

I'm not convinced that the recent additions to the wiki page reflect consensus
in this debate.  But I appreciate your attempt to summarize this debate on that
wiki page.  Maybe we should revert the recent changes on that wiki page until
there is a more explicit consensus in this debate.  My impression is that
consensus is growing towards what Guus wrote.  But this impression may be
colored by the fact that I happen to agree with what Guus wrote.

Regards,

Bart Martens

headers

Jon Dowland | 29 Jun 2012 10:22

Re: Improving our response to "duplicate" packages in Debian

On Fri, Jun 29, 2012 at 05:28:45AM +0000, Bart Martens wrote:
> I'm not convinced that the recent additions to the wiki page reflect consensus
> in this debate.  But I appreciate your attempt to summarize this debate on that
> wiki page.  Maybe we should revert the recent changes on that wiki page until
> there is a more explicit consensus in this debate.  My impression is that
> consensus is growing towards what Guus wrote.  But this impression may be
> colored by the fact that I happen to agree with what Guus wrote.

Rather than revert, I'd suggest summarizing the positions where there isn't
consensus.

headers

Josselin Mouette | 29 Jun 2012 09:24

Re: Improving our response to "duplicate" packages in Debian

Le jeudi 28 juin 2012 à 16:42 +0200, Guus Sliepen a écrit : 
> - Don't immediately start complaining to the submitter of the ITP. Just let
>   the submitter devote his/her energy to packaging.

I don’t think it is worthwile to let people devote their energy to
packaging pet applications that will disappear in 2 years time when they
find another one.

We really need to find better ways to involve new users in core teams,
and that means removing from our collective consciousness the idea that
you come in Debian to package your new favorite piece of software.

--

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

headers

Guus Sliepen | 29 Jun 2012 11:11

Re: Improving our response to "duplicate" packages in Debian

On Fri, Jun 29, 2012 at 09:24:25AM +0200, Josselin Mouette wrote:

> Le jeudi 28 juin 2012 à 16:42 +0200, Guus Sliepen a écrit : 
> > - Don't immediately start complaining to the submitter of the ITP. Just let
> >   the submitter devote his/her energy to packaging.
> 
> I don’t think it is worthwile to let people devote their energy to
> packaging pet applications that will disappear in 2 years time when they
> find another one.

You or I may not think that but clearly the one who is doing the packaging
thinks it is worthwile, and who know how many users there will be for the new
package. Nobody knows beforehand if the application will last only a year or
be there until the end of time. So we should not blame the new ITP for the
already packaged pet applications that have since disappeared.

> We really need to find better ways to involve new users in core teams,
> and that means removing from our collective consciousness the idea that
> you come in Debian to package your new favorite piece of software.

I agree we can use more members in core teams, but complaining to a maintainer
when he files an ITP is usually not a positive step in that direction. This
person will not suddenly think, "hey, you are right, I shouldn't package this
software which I thought was very useful, I should join the FTP masters
instead!"

Already the Debian website mentions lots of things people can do to improve
Debian besides packaging, and I am sure they *are* being done. However, if
there are core teams that are in desparate need of help, they should make this
known somehow. Perhaps there should be a section in the Debian Project News

(Continue reading)

headers

Andrey Rahmatullin | 29 Jun 2012 11:20

Re: Improving our response to "duplicate" packages in Debian

On Fri, Jun 29, 2012 at 09:24:25AM +0200, Josselin Mouette wrote:
> We really need to find better ways to involve new users in core teams,
> and that means removing from our collective consciousness the idea that
> you come in Debian to package your new favorite piece of software.
Unfortunately different attitudes, skill sets and other things are
required for packaging some software you have chosen for that yourself and
for doing work for one of teams.

--

-- 
WBR, wRAR

headers

Yaroslav Halchenko | 29 Jun 2012 18:20

Re: Improving our response to "duplicate" packages in Debian


On Fri, 29 Jun 2012, Josselin Mouette wrote:
> I don’t think it is worthwile to let people devote their energy to
> packaging pet applications that will disappear in 2 years time when they
> find another one.

+1

> We really need to find better ways to involve new users in core teams,

+1

> and that means removing from our collective consciousness the idea that
> you come in Debian to package your new favorite piece of software.

-10

-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org
Archive: http://lists.debian.org/20120629162040.GP5788 <at> onerussian.com

(Continue reading)

headers

Michael Hanke | 30 Jun 2012 08:41

Re: Improving our response to "duplicate" packages in Debian

On Fri, Jun 29, 2012 at 09:24:25AM +0200, Josselin Mouette wrote:
> Le jeudi 28 juin 2012 à 16:42 +0200, Guus Sliepen a écrit : 
> > - Don't immediately start complaining to the submitter of the ITP. Just let
> >   the submitter devote his/her energy to packaging.
> 
> I don’t think it is worthwile to let people devote their energy to
> packaging pet applications that will disappear in 2 years time when they
> find another one.

I think this is approaching the problem from the wrong end. Instead of
preserving the status quo and asking oracles to predict the future we
should have better means of _removing_ software that has proven to be
inferior of an equivalent alternative in Debian. The advantage is that
we have objective criteria to be able to make an informed decision --
not a guess based on heuristics and opinion. The disadvantage is that it
imposes work on other volunteers -- but see below...

> We really need to find better ways to involve new users in core teams,
> and that means removing from our collective consciousness the idea that
> you come in Debian to package your new favorite piece of software.

I have to disagree -- and I would even make the bold claim that
"packaging your favorite piece of software" is a very common (if not the
most common) entry point for _people_ into Debian. One could see the
"pet projects" as the price we need to pay to make participation in
Debian very attractive (not even talking about the role that "pet
projects" play in the context of perceived universality of Debian) .
Getting people to participate in Debian, make them become confident and
experienced is IMHO a requirement for increasing the chance of anyone
joining core teams.

(Continue reading)

headers

Russell Coker | 30 Jun 2012 09:16

Re: Improving our response to "duplicate" packages in Debian

On Sat, 30 Jun 2012, Michael Hanke <mih <at> debian.org> wrote:
> I think this is approaching the problem from the wrong end. Instead of
> preserving the status quo and asking oracles to predict the future we
> should have better means of removing software that has proven to be
> inferior of an equivalent alternative in Debian. The advantage is that
> we have objective criteria to be able to make an informed decision --
> not a guess based on heuristics and opinion. The disadvantage is that it
> imposes work on other volunteers -- but see below...

More automated bug filing systems would be a good thing.  If a package doesn't 
get used much then it tends not to get bug reports or NMUs so it can quietly 
languish without anyone noticing.

If you maintain more than a few packages it's easy to forget about some that 
don't get bug reports.

> > We really need to find better ways to involve new users in core teams,
> > and that means removing from our collective consciousness the idea that
> > you come in Debian to package your new favorite piece of software.
> 
> I have to disagree -- and I would even make the bold claim that
> "packaging your favorite piece of software" is a very common (if not the
> most common) entry point for people into Debian. One could see the
> "pet projects" as the price we need to pay to make participation in
> Debian very attractive (not even talking about the role that "pet
> projects" play in the context of perceived universality of Debian) .
> Getting people to participate in Debian, make them become confident and
> experienced is IMHO a requirement for increasing the chance of anyone
> joining core teams.

(Continue reading)

headers

Craig Small | 1 Jul 2012 00:34

Re: Improving our response to "duplicate" packages in Debian

On Sat, Jun 30, 2012 at 08:41:07AM +0200, Michael Hanke wrote:
> On Fri, Jun 29, 2012 at 09:24:25AM +0200, Josselin Mouette wrote:
> > We really need to find better ways to involve new users in core teams,
> > and that means removing from our collective consciousness the idea that
> > you come in Debian to package your new favorite piece of software.
> 
> I have to disagree -- and I would even make the bold claim that
> "packaging your favorite piece of software" is a very common (if not the
> most common) entry point for _people_ into Debian. One could see the
I'd go even further and say that the reason why people start on
something generally in Free Software projects is to "scratch their itch"
which in Debian could well mean packaing your favourite piece of
software.

I'd be surprised if many newly-minted Debian maintainers would want to
tackle a core project from day one.  There is a lot to learn and just
get used to and I'd also rather that people working on the core stuff
have some idea, as well as some history of doing the right thing.

So if we went down that way we've removed one very big incentive "your
fav project is packaged" and created a disincentive "work on highly
visible project X with all its complicated history".

> "pet projects" as the price we need to pay to make participation in
> Debian very attractive (not even talking about the role that "pet
That's a good way of putting it.  Also who can predict what is really a
pet project.  I bet the first medical related project that was ITP'ed
on Debian people were thinking 'huh, why that here?' and yet I hear now
there is quite a large and vibrant community around this sort of thing.

(Continue reading)

headers

Kevin Mark | 1 Jul 2012 14:24

Re: Improving our response to "duplicate" packages in Debian

On Sun, Jul 01, 2012 at 08:34:01AM +1000, Craig Small wrote:
> I'd go even further and say that the reason why people start on
> something generally in Free Software projects is to "scratch their itch"
> which in Debian could well mean packaing your favourite piece of
> software.

Has anyone quantized the % of tasks that a DD/DM does that are outside of their
pet projects? Meaning, once they get their itch scratched, how far outside of
their main reason for joining Debian, do they explore? Would it be useful to
game-ify people's efforts outside their 'comfort zone' (eg. a perl packager
working on Haskell, or doing debian-www work) ?
If people just work on their pet projects, is that the most typical behavior
throughout Debian's history? Do people explore more as they become more
comfortable/familiar over a number of years?

--

-- 
|  .''`.  == Debian GNU/Linux ==.| http://kevix.myopenid.com......|
| : :' :     The Universal OS....| mysite.verizon.net/kevin.mark/.|
| `. `'   http://www.debian.org/.| http://counter.li.org [#238656]|
|___`-____Unless I ask to be CCd,.assume I am subscribed._________|

Kindness is a language which the deaf can hear and the blind can read.
		-- Mark Twain

headers

Charles Plessy | 1 Jul 2012 14:32

Re: Improving our response to "duplicate" packages in Debian

Le Sun, Jul 01, 2012 at 08:24:27AM -0400, Kevin Mark a écrit :
> 
> Has anyone quantized the % of tasks that a DD/DM does that are outside of their
> pet projects? Meaning, once they get their itch scratched, how far outside of
> their main reason for joining Debian, do they explore? Would it be useful to
> game-ify people's efforts outside their 'comfort zone' (eg. a perl packager
> working on Haskell, or doing debian-www work) ?
> If people just work on their pet projects, is that the most typical behavior
> throughout Debian's history? Do people explore more as they become more
> comfortable/familiar over a number of years?

We did not quantify, but the Debian Med project has a wiki page where
its members can indicate that they "extended scope".

  http://wiki.debian.org/DebianMed/Developers

Have a nice Sunday,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org
Archive: http://lists.debian.org/20120701123237.GB24097 <at> falafel.plessy.net

(Continue reading)

headers

Chris Bannister | 2 Jul 2012 05:01

Re: Improving our response to "duplicate" packages in Debian

On Sun, Jul 01, 2012 at 08:24:27AM -0400, Kevin Mark wrote:
> Has anyone quantized the % of tasks that a DD/DM does that are outside of their
> pet projects? Meaning, once they get their itch scratched, how far outside of
> their main reason for joining Debian, do they explore? Would it be useful to
> game-ify people's efforts outside their 'comfort zone' (eg. a perl packager
  ^^^^^^^^
  Is this yet another new word?

--

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X

headers

Ben Finney | 2 Jul 2012 05:49

Re: Improving our response to "duplicate" packages in Debian

Chris Bannister <cbannister <at> slingshot.co.nz> writes:

> Is this [“game-ify”] yet another new word?

It's a neologism, yes <URL:https://en.wikipedia.org/wiki/Gamification>.

-- 
 \        “A life spent making mistakes is not only most honorable but |
  `\          more useful than a life spent doing nothing.” —anonymous |
_o__)                                                                  |
Ben Finney

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org
Archive: http://lists.debian.org/87txxqq0tm.fsf <at> benfinney.id.au

headers

Tomasz Rybak | 19 Jul 2012 11:45

Re: Improving our response to "duplicate" packages in Debian

Dnia 2012-07-01, nie o godzinie 08:24 -0400, Kevin Mark pisze:
> On Sun, Jul 01, 2012 at 08:34:01AM +1000, Craig Small wrote:
> > I'd go even further and say that the reason why people start on
> > something generally in Free Software projects is to "scratch their itch"
> > which in Debian could well mean packaing your favourite piece of
> > software.

Sorry for resurrecting old thread, but I want to give perspective of
someone who is maintaining leaf projects.  I am maintaing 3 python
packages. I have started in 2010 (beginning with pytools, then pyopencl)
and in 2011, after nvidia-cuda-toolkit landed in Debian, pycuda.
Recently I have added support for Python 3 in pytools and pyopencl.  I
am cooperating with upstream. Most of uploads were sponsored by Piotr
Ożarowski (except for one, uploading pyopencl 0.92-1 during Squeeze
freeze).  You can say I have stable situation: cooperating with one
upstream, having usual sponsor. Now I am in the process of becoming DM.

> 
> Has anyone quantized the % of tasks that a DD/DM does that are outside of their
> pet projects? Meaning, once they get their itch scratched, how far outside of
> their main reason for joining Debian, do they explore? Would it be useful to
> game-ify people's efforts outside their 'comfort zone' (eg. a perl packager
> working on Haskell, or doing debian-www work) ?
> If people just work on their pet projects, is that the most typical behavior
> throughout Debian's history? Do people explore more as they become more
> comfortable/familiar over a number of years?

Currently I am not reaching very far outside my comfort zone.  I am not
sure whether gamification would help here; maybe some list of easy tasks
to try, to decide whether I like them or not?  I am not sure whether my

(Continue reading)

headers

Andreas Tille | 3 Jul 2012 09:11

Re: Improving our response to "duplicate" packages in Debian

On Sun, Jul 01, 2012 at 08:34:01AM +1000, Craig Small wrote:
> > "pet projects" as the price we need to pay to make participation in
> > Debian very attractive (not even talking about the role that "pet
> That's a good way of putting it.  Also who can predict what is really a
> pet project.  I bet the first medical related project that was ITP'ed
> on Debian people were thinking 'huh, why that here?' and yet I hear now
> there is quite a large and vibrant community around this sort of thing.

To base the feelings expressed here on numbers I evaluated the
questionaire for Debian Med developers Charles was hinting to[1].  We
have 9DDs + 1DM inside Debian only because the Debian Med project
exists.  Of these 10 people 7 extended their scope to other teams (some
of them by leaving Debian Med more or less completely to focus on other
tasks).

I would like to stress that one of the main ideas behind Debian Pure
Blends is to dive deeply into very specific fields and "hunt" for the
specialists there to make Debian the distribution of choice for specific
workfields.  I tried to graph this idea on slide 13 of my Banja Luka
talk last year[2] and in the same way on slide 8 of my recent talk in
Grenoble[3] were I did put the focus on the fact that Debian does not
simply carry random medical stuff but we should rather see the Debian
Med project which made quite good progress to advertise Debian in the
world of biology and to some extend in medical care (which is a bit
harder).  It is my very strong opinion that if we manage to settle into
different workfields with an exceptional quality we will gain for much
more users (und thus potential developers) via cross-connections to
other fields.

When I started the MoM project[4] I kept this in mind to train the

(Continue reading)

headers

Toni Mueller | 2 Jul 2012 00:11

Re: Improving our response to "duplicate" packages in Debian

Hi,

On Sat, Jun 30, 2012 at 08:41:07AM +0200, Michael Hanke wrote:
> I think this is approaching the problem from the wrong end. Instead of
> preserving the status quo and asking oracles to predict the future we
> should have better means of _removing_ software that has proven to be
> inferior of an equivalent alternative in Debian. The advantage is that
> we have objective criteria to be able to make an informed decision --
> not a guess based on heuristics and opinion. The disadvantage is that it
> imposes work on other volunteers -- but see below...

well, what do you have in mind?

If you happen to think along the lines of bug count per package, that's
easily challenged (imho), and defining "equivalent" is also far from
providing an objective criterion.

On top of that, I happen to appreciate the choice I have in Debian,
instead of the only one true way to do things. Just think of the
"equivalence" between KDE and Gnome, or vim and emacs, for a start.
Imho, going that road is the fastest way to wind down our user base to
less than a third of the current size.

I also think that Craig and Russel are right about the incentives and
risks for newcomers not being able to scratch their itch, and failing
in a core project.

May I ask what are the driving reasons behind the advocated change with
respect to our tradision are?

(Continue reading)

headers

Ian Jackson | 2 Jul 2012 16:25

Re: Improving our response to "duplicate" packages in Debian

Michael Hanke writes ("Re: Improving our response to "duplicate" packages in Debian"):
> I think this is approaching the problem from the wrong end. Instead of
> preserving the status quo and asking oracles to predict the future we
> should have better means of _removing_ software that has proven to be
> inferior of an equivalent alternative in Debian. The advantage is that
> we have objective criteria to be able to make an informed decision --
> not a guess based on heuristics and opinion. The disadvantage is that it
> imposes work on other volunteers -- but see below...

We apparently already have people who are willing to put in work to
try to trim the contents of Debian to packages which are worthwhile,
in some sense.

Perhaps one way of reading this thread is as a request that those
people respond a bit differently the appearance of an ITP for a
package where there is similar functionality in Debian already; a
request that those wanting a leaner better Debian should take it as a
prompt to look at some of those other, existing, packages and see
whether any of them should be removed ?

If so I'm not sure I agree with that, but it would certainly be nice
if those complaining about ITPs looked at the other similar packages
in Debian already to try to actually form an opinion about the
relative merits of the old and the new.

Ian.

headers

Prince Annan Koomson | 30 Jun 2012 23:28

RE: Improving our response to "duplicate" packages in Debian

I think finding a way to involve new users is a nice idea, also reviewing members list finding the total
number of members and members which are idle can assign packages to maintain depending on their skill set
and other factors should also be considered. This will help offload some of workload on other maintainers.

Thanks.
Prince Annan Koomson.

Sent from my smartphone

-----Original Message-----
From: Russell Coker <russell <at> coker.com.au>
Sent: Saturday, June 30, 2012 8:16
To: debian-devel <at> lists.debian.org
Subject: Re: Improving our response to "duplicate" packages in Debian

On Sat, 30 Jun 2012, Michael Hanke <mih <at> debian.org> wrote:
> I think this is approaching the problem from the wrong end. Instead of
> preserving the status quo and asking oracles to predict the future we
> should have better means of removing software that has proven to be
> inferior of an equivalent alternative in Debian. The advantage is that
> we have objective criteria to be able to make an informed decision --
> not a guess based on heuristics and opinion. The disadvantage is that it
> imposes work on other volunteers -- but see below...

More automated bug filing systems would be a good thing.  If a package doesn't 
get used much then it tends not to get bug reports or NMUs so it can quietly 
languish without anyone noticing.

If you maintain more than a few packages it's easy to forget about some that 
don't get bug reports.

(Continue reading)

headers

Stefano Zacchiroli | 2 Jul 2012 17:55

Re: Improving our response to "duplicate" packages in Debian

On Thu, Jun 28, 2012 at 04:42:10PM +0200, Guus Sliepen wrote:
> I believe our current way of responding to ITPs for software that
> duplicates the functionality other software that is already in Debian
> is wrong. We have a very lengthy discussion everytime such an ITP
> happen, but usually they change nothing (the submitter just goes ahead
> with packaging it) or worse, they scare away the maintainer along with
> his/her ITP.

Hi Guus, thanks a lot for this mail of yours, which I find very
constructive.

> So, keep the friction low for maintainers who are actually doing
> something, and if you really feel strongly about duplicate software
> polluting Debian, concentrate your efforts at the existing packages.

I believe you hit the nail on the head for the "ITP threads" problem.

Complaining *just* because there are similar programs in the archive is
demotivating for the ITP-ers who are simply trying to contribute to
Debian in a way they are comfortable with. That should be avoided. Also
because, as others mentioned, the dichotomy between working on "leaf"
packages and working on "core" teams is not necessarily true. In fact, I
know many many people currently active in core teams who started
contributing from leaf packages, and then gradually increased their
Debian involvement. To be honest, I hardly imagine how it could be
otherwise. If those experiences are representative of more general
trends, not bashing ITP-ers of leaf packages is actually an investment
in the future of the Project (and core teams).

But then it's true that some kinds of leaf packages induce archive-wide

(Continue reading)

headers

Guus Sliepen | 4 Jul 2012 11:40

Bug#680174: Improving our response to "duplicate" packages in Debian

Package: developers-reference
Version: 3.4.8
Severity: wishlist
Tags: patch

On Mon, Jul 02, 2012 at 09:55:23AM -0600, Stefano Zacchiroli wrote:

> On Thu, Jun 28, 2012 at 04:42:10PM +0200, Guus Sliepen wrote:
> > I believe our current way of responding to ITPs for software that
> > duplicates the functionality other software that is already in Debian
> > is wrong.>
[...]
> Guus, after having collected feedback from this thread, could you please
> propose a patch to devref for documenting the outcome of this
> discussion?

Sure. Attached is a patch against the developers-reference source. It can
probably be improved, any comments are welcome.

--

-- 
Met vriendelijke groet / with kind regards,
      Guus Sliepen <guus <at> debian.org>

Attachment (handling-itp-bug-reports.diff): text/x-diff, 3793 bytes

headers

Charles Plessy | 10 Jul 2012 10:50

Bug#680174: Improving our response to "duplicate" packages in Debian

Le Wed, Jul 04, 2012 at 11:40:40AM +0200, Guus Sliepen a écrit :
> 
> Attached is a patch against the developers-reference source. It can
> probably be improved, any comments are welcome.

Dear Guus,

thank you for your patch.  Here are a few comments.

> diff --git a/beyond-pkging.dbk b/beyond-pkging.dbk
> index 371fba2..5205222 100644
> --- a/beyond-pkging.dbk
> +++ b/beyond-pkging.dbk

I think that everything could be pooled in section 5.1 (New packages).

> +<para>If you dislike the software the new maintainer wants to package,
> +you probably shouldn't complain about this to the maintainer, they are merely packaging it. Complain to
upstream instead.

I propose to delete « Complain to upstream instead ». We do not know if it will
be productive so let's avoid sharing the responsibility for starting heated
discussions upstream.

> +You should also consider if your prospective package is suitable for inclusion
> +in Debian. The software must of course be legally redistributable, and if you
> +want it to be included in the main section, its license must be compatible with
> +the DFSG.

I think that that the current consensus is that « in Debian » means the same as

(Continue reading)

headers

Charles Plessy | 10 Jul 2012 10:50

Bug#680174: Improving our response to "duplicate" packages in Debian

Le Wed, Jul 04, 2012 at 11:40:40AM +0200, Guus Sliepen a écrit :
> 
> Attached is a patch against the developers-reference source. It can
> probably be improved, any comments are welcome.

Dear Guus,

thank you for your patch.  Here are a few comments.

> diff --git a/beyond-pkging.dbk b/beyond-pkging.dbk
> index 371fba2..5205222 100644
> --- a/beyond-pkging.dbk
> +++ b/beyond-pkging.dbk

I think that everything could be pooled in section 5.1 (New packages).

> +<para>If you dislike the software the new maintainer wants to package,
> +you probably shouldn't complain about this to the maintainer, they are merely packaging it. Complain to
upstream instead.

I propose to delete « Complain to upstream instead ». We do not know if it will
be productive so let's avoid sharing the responsibility for starting heated
discussions upstream.

> +You should also consider if your prospective package is suitable for inclusion
> +in Debian. The software must of course be legally redistributable, and if you
> +want it to be included in the main section, its license must be compatible with
> +the DFSG.

I think that that the current consensus is that « in Debian » means the same as

(Continue reading)

headers

Guus Sliepen | 4 Jul 2012 11:40

Bug#680174: Improving our response to "duplicate" packages in Debian

Package: developers-reference
Version: 3.4.8
Severity: wishlist
Tags: patch

On Mon, Jul 02, 2012 at 09:55:23AM -0600, Stefano Zacchiroli wrote:

> On Thu, Jun 28, 2012 at 04:42:10PM +0200, Guus Sliepen wrote:
> > I believe our current way of responding to ITPs for software that
> > duplicates the functionality other software that is already in Debian
> > is wrong.>
[...]
> Guus, after having collected feedback from this thread, could you please
> propose a patch to devref for documenting the outcome of this
> discussion?

Sure. Attached is a patch against the developers-reference source. It can
probably be improved, any comments are welcome.

--

-- 
Met vriendelijke groet / with kind regards,
      Guus Sliepen <guus <at> debian.org>

Attachment (handling-itp-bug-reports.diff): text/x-diff, 3793 bytes