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 07-01-2012, 12:32 PM
Charles Plessy
 
Default 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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120701123237.GB24097@falafel.plessy.net">http://lists.debian.org/20120701123237.GB24097@falafel.plessy.net
 
Old 07-01-2012, 02:10 PM
Philipp Kern
 
Default 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
 
Old 07-01-2012, 10:11 PM
Toni Mueller
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120701221120.GA27264@spruce.wiehl.oeko.net">http ://lists.debian.org/20120701221120.GA27264@spruce.wiehl.oeko.net
 
Old 07-02-2012, 03:01 AM
Chris Bannister
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120702030137.GY15677@tal
 
Old 07-02-2012, 03:49 AM
Ben Finney
 
Default Improving our response to "duplicate" packages in Debian

Chris Bannister <cbannister@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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87txxqq0tm.fsf@benfinney.id.au">http://lists.debian.org/87txxqq0tm.fsf@benfinney.id.au
 
Old 07-02-2012, 02:25 PM
Ian Jackson
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20465.44890.627837.789458@chiark.greenend.org.uk"> http://lists.debian.org/20465.44890.627837.789458@chiark.greenend.org.uk
 
Old 07-02-2012, 03:55 PM
Stefano Zacchiroli
 
Default 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 »
 
Old 07-03-2012, 07:11 AM
Andreas Tille
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120703071107.GA4169@an3as.eu">http://lists.debian.org/20120703071107.GA4169@an3as.eu
 
Old 07-19-2012, 09:45 AM
Tomasz Rybak
 
Default 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.rybak@post.pl> GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
 

Thread Tools




All times are GMT. The time now is 04:53 AM.

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