From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-dev+bounces-45042-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1Q3wq6-0004Ut-RW
for garchives@archives.gentoo.org; Sun, 27 Mar 2011 20:45:35 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id E32191C08F;
Sun, 27 Mar 2011 20:45:25 +0000 (UTC)
Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181])
by pigeon.gentoo.org (Postfix) with ESMTP id ED8BE1C05F
for <gentoo-dev@lists.gentoo.org>; Sun, 27 Mar 2011 20:44:56 +0000 (UTC)
Received: by wyi11 with SMTP id 11so2345973wyi.40
for <gentoo-dev@lists.gentoo.org>; Sun, 27 Mar 2011 13:44:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:sender:in-reply-to:references:date
:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
bh=nE9kTnqwE44tfckasxlgSgyW6IEkJ7FNk/JKYWAMai8=;
b=Igvv8s2c1CW1Sq52KM9VTbMNyMUo3m6jAibIXxUJ6gnPmemwNZr9BRcM1e113OytDV
HtBv94+cScyVjeboZmIraVnqpjorLlCCDOMDNfPhvRYHrfTfGGWMw8+TsHpTMLj2j8yg
ibqf8mUSwdrublKFRQJG1LMlavK1E5veYAX+g=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:sender:in-reply-to:references:date
:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
b=VG9DByFKOI+uVtpsSczWJ6Y6dQ05QdDamZbxblElfyQ76rb1+zWTcBzmVKH7bdrh93
kybqr5ZrTD18j8oHot0bP+LO4X4obxZOVEcwVZl9xBHX+oQ/KOvsiqX+alRy0brZBDWA
6qbx7/m/ov1SN++0Cn1OX3RHAumYPQkV0njAs=
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.227.208.212 with SMTP id gd20mr3052855wbb.210.1301258695751;
Sun, 27 Mar 2011 13:44:55 -0700 (PDT)
Sender: freemanrich@gmail.com
Received: by 10.227.147.82 with HTTP; Sun, 27 Mar 2011 13:44:55 -0700 (PDT)
In-Reply-To: <AANLkTikxAMHSBuxPTeDv0XOr9P_fiKhtOnAad6CWNzeV@mail.gmail.com>
References: <20110326055210.E906D20054@flycatcher.gentoo.org>
<4D8EC104.4090503@gentoo.org>
<AANLkTik=cLPnD5Y7akyM0xsPgOC7+cvVOh=bj1Opir_y@mail.gmail.com>
<4D8F3BE8.5050300@gentoo.org>
<AANLkTikrbqVO6y-Pym+gEpGbEJYtRZmH8JnbpWcY+k5n@mail.gmail.com>
<AANLkTimoW4QOtSVNVKZZurp9XaSRaQApD9QEUxafxw=m@mail.gmail.com>
<AANLkTikxAMHSBuxPTeDv0XOr9P_fiKhtOnAad6CWNzeV@mail.gmail.com>
Date: Sun, 27 Mar 2011 16:44:55 -0400
X-Google-Sender-Auth: bvxILfdDlQAPgEmoO8yptSIPyAQ
Message-ID: <AANLkTik6BBvKKR8iGQvTc4XAoKCmEh=gwf6RUgaemiKt@mail.gmail.com>
Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in
dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: Nirbheek Chauhan <nirbheek@gentoo.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Archives-Salt:
X-Archives-Hash: 65466dfa535f04ea26ca08b6a0918c49
On Sun, Mar 27, 2011 at 3:40 PM, Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> It's really simple:
>
> (a) If the package has plenty of users, there should be no problems
> finding a maintainer or a proxy-maintainer.
Uh, I guess that's why we are flooded with people wanting to be
devs... There are lots of high-use packages that could use more
maintainers. I'm not aware of any teams that would turn away help.
> (b) If the package has few users and is high-maintenance, it's either
> already broken, or will get broken soon without a maintainer. Find one
> or remove it!
If it doesn't build, then it can be removed. Nobody is arguing with
that. If you think that someday it might not build, then just wait a
few months and if you're right you can satisfy your itch to prune the
tree...
> (c) If the package has few users and is low-maintenance, package.mask
> it so we can figure out who the users are, and we can get them to
> proxy-maintain it, it's so little work anyway, right?
Uh, package.mask is not intended to be an end-user communication tool.
News is slightly better in this respect, but again this is not its
purpose.
We shouldn't be punishing people for not becoming developers. I don't
want to use a distro that throws up warning messages every few months
because some package I've been using had its developer retire, and I'm
a developer. If it breaks and I care enough about it, I'll rescue it.
If I'm passionate about it, I'll step in before it breaks. Holding
users ransom is not the solution.
> (d) If the package has very few or no users, what the hell is it doing
> unmaintained in the tree? It's just eating up disk inodes and space.
>
Uh, and how much does the inodes, space, and bandwidth consumed by
those ~700 m-n packages actually cost. Are we talking about going
through wailing and gnashing of teeth so that our stakeholders can
save a total of 45 cents worth of disk space across 50 mirrors and
50,000 Gentoo boxes over the next 5 years? If one person is getting
use out of it, and nobody is getting hurt, and it costs a few inodes,
I'm fine with that.
> We all like to boast about how gentoo has 15,000 packages, but we
> neglect to mention that more than 1000 of these are either
> unmaintained or very poorly maintained. And this is a very
> conservative number.
I don't know anybody who uses Gentoo because of our huge repository.
Sure, compared to LFS it is big. Compared to most major distros,
Gentoo isn't all that large. If all somebody wants is a ton of
packages they're going to run Debian or whatever. Sure, we have a
nice repository and we should be proud of it, but I don't think
anybody is trying to over-inflate our repo size just by loading it up
with junk.
The thing I don't understand here is that there seems to be some
perception that having stuff in the tree or in Bugzilla costs us
something. Sure, at some level it does, and if 99.99% of portage were
junk data, then we might have a problem. However, database records
and inodes come billions for the dollar. Having a few percent more
churn so that we can more gracefully handle the lifecycle of packages
doesn't seem like much of a sacrifice. If you're tired of looking at
junk when you search bugzilla, then you need to think about how you're
searching it. These sorts of arguments come up at work all the time
and unless there is some kind of regulatory issue at stake or real
loss of revenue associated with lost opportunities, chasing down
unnecessary database records to be "tidy" almost always costs far more
than it saves.
I'd be shocked if the total cost to our sponsors in mirror space for
m-n packages exceeded the value of time spent by everybody reading
this thread. I think we should be practical - I'm all for giving
treecleaners a free hand when packages really cause problems, but
being anal-retentive just for the sake of doing so doesn't seem to
create real value.
Rich