From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-66441-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 DB0E213877A
for <garchives@archives.gentoo.org>; Tue, 1 Jul 2014 13:48:31 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 84B8FE0B05;
Tue, 1 Jul 2014 13:48:26 +0000 (UTC)
Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id A5E13E0AAF
for <gentoo-dev@lists.gentoo.org>; Tue, 1 Jul 2014 13:48:25 +0000 (UTC)
Received: by mail-vc0-f182.google.com with SMTP id il7so9167270vcb.27
for <gentoo-dev@lists.gentoo.org>; Tue, 01 Jul 2014 06:48:25 -0700 (PDT)
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;
bh=H189/PHyBcQmMRWn+/6FhUs9ric5pIwiZFJTGXvtHrw=;
b=QNszU3MRgcZazlyoh3VIrdBvDGFNVal2QgYSHYctlbH7pw6fy+Z9BG91EfyOm78/gl
dVKpd5RdC4CQSu7rUVhIDeB606BdW78K3Du6FKp+GXgPQiMmTDlsr9vL4dOVSpwXS8OZ
VgyQuA8JgPQuvwyh+7/Q3t63j+SdyaZSwSRIHRKCyzewUCLbC9uPw5gtc2eQnGijLbH3
3Jt916u4tbnbfDxIrRgspPdUit0dmerWcRoJbLHycUt2ke9shN1LO0VIlbYu2umcqvjY
O8/vdgRWn24DA0BhrnTyuYN840Ij/g1zFwp1wta0kBiwpSu82d1Ui8i1cUCo9DAt28j0
Ahng==
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.58.210.168 with SMTP id mv8mr41120059vec.12.1404222504883;
Tue, 01 Jul 2014 06:48:24 -0700 (PDT)
Sender: freemanrich@gmail.com
Received: by 10.52.72.19 with HTTP; Tue, 1 Jul 2014 06:48:24 -0700 (PDT)
In-Reply-To: <53B2AC6E.6010909@gentoo.org>
References: <20140630040153.GA668@linux1>
<CAGfcS_mHOeQb-S3Tcfz4MYdJ9vwjFamVxqNQGxiEB1+4+YYoGQ@mail.gmail.com>
<20140630161555.15ab3403@marga.jer-c2.orkz.net>
<53B2AC6E.6010909@gentoo.org>
Date: Tue, 1 Jul 2014 09:48:24 -0400
X-Google-Sender-Auth: mdGpAI2lb4rJdKKpJdl56O7__VU
Message-ID: <CAGfcS_kjd22d-54zPHKt1k4vnWzdb8t-mk07KfSus45xbQ-c8Q@mail.gmail.com>
Subject: Re: [gentoo-dev] package.mask vs ~arch
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Content-Type: text/plain; charset=UTF-8
X-Archives-Salt: 36bfaaf7-bca1-4db3-a8da-51675679d3c6
X-Archives-Hash: 73f562f997e94024f6df474731267ed7
On Tue, Jul 1, 2014 at 8:41 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 06/30/14 22:15, Jeroen Roovers wrote:
>> On Mon, 30 Jun 2014 09:25:27 -0400
>> Rich Freeman <rich0@gentoo.org> wrote:
>>
>>> Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED
>>> AT ALL. The maintainer knows that they compile, and that is it.
>>
>> Developers who "HAVEN'T [...] TESTED AT ALL" and still commit their
>> changes to the tree should immediately hand in their toys and leave
>> the project.
>>
>
> I usually avoid overlays (best way to make things hard to find), so when
> there's stuff that upstream says is experimental (e.g. perl6/rakudo with
> the MoarVM backend) I have no issue with adding it as un-keyworded
> ebuilds to the tree. That way it's easy to test, and once there's a bit
> more confidence that it works well enough it's trivial to keyword.
>
If the goal is to reduce clutter in the profiles then this could be a
good alternative. Nothing would prevent a maintainer from sticking a
comment in the ebuild as well.
Hate to derail this, but another option would be to migrate
package.mask to a directory (eventually) and manage masks by project
or by date. Projects could create standing files when needed, and
misc masks would go into a file named by year/quarter. Then anybody
looking in the directory can spot projects that are dead, or files
which are old. Either would be easier to clean up.
Obviously restructuring the profiles entirely as has been suggested
will help, though not for masks like these.
Rich