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 situation reflects others, but when going into new territory in the beginning I need few easy steps and feeling that I can ask someone without interrupting him/her. Then, as situation progresses, I feel more eager to experiment. I do not feel I can see _the step_ between managing own packages and doing something more core. When I read about helping with core I do not even know where to start. How to decide what is this other activity that should be done and I'll feel confident enough to try? Best regards. -- Tomasz Rybak tomasz.ry...@post.pl GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
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 experts in specific programs (were I as a generalist have no good chance to test) some packaging skills. As some result I can say we now have established quite strong connection to an upstream community for a very powerful hospital management system (VistA) which finally could enable us to establish pure Debian in large hospitals once the packaging is finalised. The underlying database system (MUMPS) is also used in some GIS applications (at least Ean Schuessler expressed some interest because of this) which somehow proves my point of cross connections. We also have Debian Edu that made a big progress in schools, we have a GIS team, a multimedia team, a games team and others which to my perception are not that visible as they should. We also have Debian Science which is a great resource to start into more specific sciences and I think the last Debian Science workshop was a good start for doing so. In short: I would not consider specific packages as pet programs but rather as an exceptional chance for Debian to spread into specific fields and find new engaged users there because they do not find support by some other system. Kind regards Andreas. [1] http://wiki.debian.org/DebianMed/Developers [2] http://people.debian.org/~tille/talks/20110728_blends/ [3] http://people.debian.org/~tille/talks/20120625_debian-med/ [4] https://wiki.debian.org/DebianMed/MoM -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120703071107.ga4...@an3as.eu
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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20465.44890.627837.789...@chiark.greenend.org.uk
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
costs that should be monitored. For instance forks, which you mentioned,
induce maintenance costs on the security team which are very similar to
those induced by code copies that we try to avoid in the archive.
It's a trade off then, and it seems to me that the guidelines you
propose are a good compromise. They ask not to complain gratuitously,
but rather detail reasons for doing so, putting some research burden on
the complainers. That is good, more productive and less socially awkward
than the more easy option of just asking do we really need this in the
archive?.
Guus, after having collected feedback from this thread, could you please
propose a patch to devref for documenting the outcome of this
discussion?
Cheers.
PS as related work on this topic, I also vaguely remember a post by
Joey Hess discussing the drawbacks of -devel culture of tearing apart
ITPs. I can't seem to find it right now, anyone else has a pointer to
it?
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701122427.GB8356@horacrux
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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701123237.gb24...@falafel.plessy.net
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 signature.asc Description: Digital signature
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? Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701221120.ga27...@spruce.wiehl.oeko.net
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120702030137.GY15677@tal
Re: Improving our response to duplicate packages in Debian
Chris Bannister cbannis...@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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txxqq0tm@benfinney.id.au
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. If it would work otherwise, we could just post a job-ad on LinkedIn: Debian security team is looking for skilled developers. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120630064107.GA20814@meiner
Re: Improving our response to duplicate packages in Debian
On Sat, 30 Jun 2012, Michael Hanke m...@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. Yes. Also I don't think that the members of core teams really want to have people learning while maintaining their packages. When people inevitably stuff up while learning things it's good to do so while working on something that's not so important. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201206301716.05650.russ...@coker.com.au
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 russ...@coker.com.au Sent: Saturday, June 30, 2012 8:16 To: debian-devel@lists.debian.org Subject: Re: Improving our response to duplicate packages in Debian On Sat, 30 Jun 2012, Michael Hanke m...@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. Yes. Also I don't think that the members of core teams really want to have people learning while maintaining their packages. When people inevitably stuff up while learning things it's good to do so while working on something that's not so important. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au [The entire original message is not included] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fef6f76.4e640e0a.79ab.a...@mx.google.com
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. Some sort of cull for dead projects is definitely a good idea! -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120630223401.gd7...@enc.com.au
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? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201206290055.16220.hol...@layer-acht.org
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 : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1340954665.3646.280.camel@pi0307572
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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629081013.gb...@p12n.org
Re: Improving our response to duplicate packages in Debian
On Fri, Jun 29, 2012 at 05:28:45AM +, 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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629082237.GB30194@debian
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/Linuxhttp://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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629084930.gb9...@codelibre.net
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 listing teams in need of help, or in general, non-packaging tasks that need to be done. Adding (a link to) a list on http://www.debian.org/intro/help or similar pages might help too. -- Met vriendelijke groet / with kind regards, Guus Sliepen g...@debian.org signature.asc Description: Digital signature
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 signature.asc Description: Digital signature
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. -- 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629161849.go5...@onerussian.com
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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629162040.gp5...@onerussian.com
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 Debian, in what shape they are, whether they have active upstream and downstream maintainers. Complain about the worst package in that selection instead. Good idea! - Go to the root of the problem: find out why upstream thinks they need to write their software. Maybe they can be convinced to combine their efforts with that of upstreams of similar packages. The ITP submitter should try that himself, I think. I'd expect that this is rather an RFP issue than a ITP issue, except maybe when someone changes an RFP to an ITP. But most ITPs come from people who already have reason to use that software they want to package. 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. Thanks again for that very constructive and calm mail on that topic! Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120628160411.ge3...@sym.noone.org
Re: Improving our response to duplicate packages in Debian
I really like these suggestions. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120628160643.GB11366@debian
Re: Improving our response to duplicate packages in Debian
Guus Sliepen g...@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. -- \ “Isn't it enough to see that a garden is beautiful without | `\ having to believe that there are fairies at the bottom of it | _o__) too?” —Douglas Adams | Ben Finney pgp3Jqpm87Xaa.pgp Description: PGP signature
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629025153.gn5...@onerussian.com
Re: Improving our response to duplicate packages in Debian
On Fri, Jun 29, 2012 at 11:24:44AM +1000, Ben Finney wrote: Guus Sliepen g...@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 that research. - 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. If this is part of analyzing why some alternatives exist, then this belongs to the work that can be done by anyone, see above. 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. I think that what Guus Sliepen wrote is quite reasonable and good for Debian. An ITP is, in my opinion, just an intent to package, and thereby only an intent to take responsibility on the maintenance of the mentioned package. Anyone can do the effort to find good reasons to object against the ITP, and that is OK, in my opinion. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629052042.ga26...@master.debian.org
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629052845.gb26...@master.debian.org
