From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 676F513877A for ; Mon, 30 Jun 2014 13:25:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C343FE096B; Mon, 30 Jun 2014 13:25:29 +0000 (UTC) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D2118E0937 for ; Mon, 30 Jun 2014 13:25:28 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id hy4so7495987vcb.20 for ; Mon, 30 Jun 2014 06:25:28 -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=zjcRbL2Z0xQA686isR0aFgaD/pYyhQXFShALlXearoI=; b=dWb67TYdpKyGeExCiTR/zk2yXHY62JgGGQ9OQeVRuhM81riblmj3CtCe3P8fRmbgnk lpqbJLBm5jn4XEdD5DTNV0G7AbliIo8XFiggct8lodPjnpykE+ba1zxcTm+mwC3PGSqK sZiYTIRITIF1SvjCmSFJXw2ZUm1qJcPhnvMoL1a/Ow3PidxxRwOgwjP2kU5sTDDRVDrP o+b33n7ymO3l/sofAGIcWO9bkF5XTrP2xJcmvWjYhde7fM9cw93R1t/2u3MvjXCJrhqr LLqdrh8aUjVdxLiDM2AwKUC7SPmYIeLd/UfHmKdFDo2dlLfBo/3Q2Ew7XXYNmOc8xrI3 JQ8w== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.220.92.135 with SMTP id r7mr38001490vcm.11.1404134727883; Mon, 30 Jun 2014 06:25:27 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.72.19 with HTTP; Mon, 30 Jun 2014 06:25:27 -0700 (PDT) In-Reply-To: <20140630040153.GA668@linux1> References: <20140630040153.GA668@linux1> Date: Mon, 30 Jun 2014 09:25:27 -0400 X-Google-Sender-Auth: s-WBhtX7_eRKRTcpXM06Uvg300A Message-ID: Subject: Re: [gentoo-dev] package.mask vs ~arch From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 6c6e6ea4-23b9-4783-b0a2-5cce4e3e72fd X-Archives-Hash: 0150627bfd724fe2ad32ec5c61fd2dc6 On Mon, Jun 30, 2014 at 12:01 AM, William Hubbs wrote: > > On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote: >> On Sun, Jun 29, 2014 at 8:36 AM, hasufell wrote: >> > This is still too vague for me. If it's expected to be short-term, then >> > it can as well just land in ~arch. >> >> A package that hasn't been tested AT ALL doesn't belong in ~arch. >> Suppose the maintainer is unable to test some aspect of the package, >> or any aspect of the package? Do we want it to break completely for >> ~arch? In that event, nobody will run ~arch for that package, and >> then it still isn't getting tested. > > I'm not saying that we should just randomly throw something into ~arch > without testing it, but ~arch users are running ~arch with the > understanding that their systems will break from time to time and they > are expected to be able to deal with it when/if it happens. ~arch is > not a second stable branch. 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. Or maybe they tested it in a very limited set of circumstances but know that other untested circumstances are important to the users and they have definite plans to get them tested. > In particular, I would argue that for system-critical packages, users > should be very careful about running ~arch unless they know what the > fallout can be. I agree. I think ~arch should break far more often than it does today. However, I wouldn't extend that to sticking stuff in ~arch that hasn't even been executed. If it is THAT unstable then nobody will want to run it, and that defeats the goal of having more testing. > Take a look at profiles/package.mask. You will see many packages in > there with the description, "masked for testing" on their masks, with no > bug references, that have been there for multiple years. My view is we > should either get those masks resolved or boot the affected > packages/versions out of the tree. If they haven't received rudimentary > testing by now, it is pretty obvious that no one cares about them. Are they even maintained? If not maintained, then leave them alone until treecleaned. If they are maintained, then I'd be interested in hearing from maintainers as to what they're up to. I wouldn't just remove the mask unless somebody is actually going to co-maintain. The issue of absentee maintainers is a different one than masks, though obsolete masks is a symptom of it just like obsolete ebuilds are. Rich