From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-63578-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 29C16138247
for <garchives@archives.gentoo.org>; Fri, 15 Nov 2013 13:33:35 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id CD445E0A43;
Fri, 15 Nov 2013 13:33:16 +0000 (UTC)
Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id CD616E0A02
for <gentoo-dev@lists.gentoo.org>; Fri, 15 Nov 2013 13:33:15 +0000 (UTC)
Received: by mail-vb0-f51.google.com with SMTP id w5so2743363vbf.38
for <gentoo-dev@lists.gentoo.org>; Fri, 15 Nov 2013 05:33:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:content-type:content-transfer-encoding;
bh=H7AD6jrP9E0VnkncEyLRFnKGXdlxpYCvsu6eMLdyRqE=;
b=08CyCT2WwBnTbOV6VDB7CpGyjdKWAqz+3jInqBCGlGVlLAeQDZpGBcCEooV5g9XS1n
S6PWXZMGihqFsAqBzGqOr17zToMk9k/RpalQshTrVBndbuoozluyM2t6L9232FOAuLrT
mXrAFLQLzrc/8NUEgKUyBACkCu5zutCQFVIgO1nUfpgvrqnfehvWBOYme7sumKfww2sd
sbvQSK3CemJVb7nj4JoEkRnMzHzanxqJ/Y0aDS3QKWaB/8pRbJlGyTb3iIN2EBLrnOye
q3oPUTuj+7yWl0uUdlEcPQUduz1/dYMW83BRHls+UytqCQPhimxcymtFf89pvptdhDj4
OjsA==
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
X-Received: by 10.52.98.194 with SMTP id ek2mr3839703vdb.11.1384522395036;
Fri, 15 Nov 2013 05:33:15 -0800 (PST)
Sender: freemanrich@gmail.com
Received: by 10.52.108.199 with HTTP; Fri, 15 Nov 2013 05:33:14 -0800 (PST)
In-Reply-To: <CAB9SyzRX38zFT8ZKV+kNNfc2PnHqqisXSDUUbNvTVCQvdzDdrg@mail.gmail.com>
References: <slrnl86l1s.j7e.vaeth@lounge.imp.fu-berlin.de>
<20131113151012.04145837@gentoo.org>
<5283948F.1000409@gentoo.org>
<52841023.9010208@gentoo.org>
<20131114061328.09136f6f@gentoo.org>
<CAB9SyzTB3Nqd8bsFpRoFvgU-RHuB4W7CG76La6qu-WQ4O7kS0g@mail.gmail.com>
<CAGfcS_kJM+0_BykpaXCcxRXi9Tw2jz=jx3Khsa6Ou_3uX6mUOA@mail.gmail.com>
<CAB9SyzSqd1fW=v1NOjetHKCX0+WxHNgWreC5JqUsEZj4RaFL3A@mail.gmail.com>
<CAGfcS_nrGjs4hw0udBFeCbHyNR4=x6GK_YNuTzNtm1gL+XKayQ@mail.gmail.com>
<CAB9SyzRyjeEfWLWLw82W+aZE1gDowgnbaKwRurMRR7V2kx0ABA@mail.gmail.com>
<CAGfcS_ka=m0EjoSdTX2QgF4oN30zpUEm+C=5nTZxT-jBfzD4rQ@mail.gmail.com>
<CAB9SyzRX38zFT8ZKV+kNNfc2PnHqqisXSDUUbNvTVCQvdzDdrg@mail.gmail.com>
Date: Fri, 15 Nov 2013 08:33:14 -0500
X-Google-Sender-Auth: 6lgFFBjgzipwnuSYRgB7PIrNxHo
Message-ID: <CAGfcS_=L2L5iGM0Z7k-xK9YayPS7uLSHw-T7Uz5qJMqKOQ4nfQ@mail.gmail.com>
Subject: Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 1627ebad-c19c-46c6-9fec-35f7bd2e17c4
X-Archives-Hash: cbe1c53e8928dbfe36c62a2453fb1d3e
On Fri, Nov 15, 2013 at 1:53 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>
> I don't really want to bring up this episode again, but it is a
> telling example, which you asked for.
I appreciate that. I did ask for an example. I'll also limit my
comments just to things that I think are more helpful moving forward.
>
> As can be seen from the ChangeLog, I was the primary maintainer.
Depends on your definition of maintainer. If you define maintainer as
somebody who has actually been doing work on a package, then you were.
If you define it as the person listed in metadata.xml, then you
weren't.
Ideally those should match, so that when projects have to go running
around the tree making changes they don't have to read between the
lines to figure out who is the right contact for any particular
package.
They match now, which is good.
>
> I am even tempted to undo the multilib changes to freetype, since it
> is still causing trouble (just search for freetype bugs and see how
> often multilib pops up).
Well, make sure you talk to the OTHER maintainer for that package,
which is the multilib team, before doing that. You don't own the
package - you just help to maintain it. I don't want to rehash the
thread from last summer - I do appreciate your feelings and I'm trying
to find a balance. I want to appreciate the fact that maintainers
have the largest investment in their packages, but at the same time
those working on projects are investing in Gentoo as well.
>>
>> Micha=C5=82 did add the multilib project as a co-maintainer, taking
>> responsibility for dealing with the multilib-related issues long-term.
>> In my mind this is the sort of things projects should do.
>
> Indeed, but more communication with the current actual maintainers of
> the package in question should also be part of that.
You're both "actual" maintainers now. Certainly I agree that you
should be talking to each other. :) I'd hope that things are going
better now, but if they aren't I'd hope that Comrel would provide some
assistance here.
>
> I am also cautiously optimistic about a renewed QA team, which could
> be involved more in this kind of issues.
I tend to agree here, but their role isn't to pick winners so much as
to defend the general integrity of the tree. I think the challenge is
figuring out how good, "good enough," is before these packages end up
in ~arch (which IS intended for TESTING packages, but packages that
are fairly likely to work with some maintainer testing already).
> If you say council should take more of a leadership role, then maybe
> this issue can be decided by council and a clear direction be taken by
> the distro as a whole? Then those who oppose the choice made can
> either put up or shut up, and we can all work at implementing the
> chosen solution.
Should we pick an init system while we're at it? :)
Honestly, I don't think we can really choose anything at this point as
none of the solutions are really fully-baked. If the Council simply
pronounced support for one of them the only result would be that
people might stop working on the other two, with no further progress
on the chosen one. Then if that one dies on the vine we're stuck.
I do have thoughts around things that could be improved, but I don't
think either of the new options are at the point where they make
sense. Both options really have to progress further on their own
before we can think about standardizing/etc.
Rich