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 49F7213877A for ; Mon, 30 Jun 2014 20:03:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6E5B6E0B0D; Mon, 30 Jun 2014 20:02:37 +0000 (UTC) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by pigeon.gentoo.org (Postfix) with ESMTP id 5FADCE0ADE for ; Mon, 30 Jun 2014 20:02:21 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta13.emeryville.ca.mail.comcast.net with comcast id LihP1o0041wfjNsADk1z06; Mon, 30 Jun 2014 20:01:59 +0000 Received: from [192.168.1.13] ([50.190.84.14]) by omta23.emeryville.ca.mail.comcast.net with comcast id Lk1x1o00K0JZ7Re8jk1zmB; Mon, 30 Jun 2014 20:01:59 +0000 Message-ID: <53B1C22F.1010101@gentoo.org> Date: Mon, 30 Jun 2014 16:01:51 -0400 From: Joshua Kinard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] package.mask vs ~arch References: <20140630040153.GA668@linux1> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1404158519; bh=28AFNfcCx0M6c8vR1cqhYpYs/IOqfyyMVPQp56qbtLY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IT968hc3EjO7NJcMTJIEjuaidPG6QYE2MY4jGZfxX9frFfbkloXPJhK1QtE40VuQu vpKEOZNiGMh8aDWx2Pddh7RUGwk5IVpWSOtac7EQaIr8pLC2wPRnHXUM11EYHs3Gfy coloy9E8BzK7oWg8Z0+7vfiZ6TgLWIjGmYqQGhYwZijjMaMma14LZTjvlE5REsThpO dEjNPsoke6ee4NYm7V8LtCZk1/oGb2nv4FML5T5X0bSSPKGBUDJNXUsWY67zGbv2qf jd9qVyNBAfsB54SI5+2jD0aiFOFVimC+lTKuFqRVsazo9oix4AJiXZZlm2G2BMREv+ 96pCCUkFHjUtg== X-Archives-Salt: cb70195d-4988-4eea-a790-fbfe23a2bbb1 X-Archives-Hash: df55b7d40803f1b1819d903f9a163f14 On 06/30/2014 09:25, Rich Freeman wrote: > 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. I think what needs to be defined here is "testing". What if I know of a group of packages that are not only open-source and compile w/o major issues, but are in use in enterprise environments, and not yet in Gentoo? Would not a "compile and ship it" approach, into "~arch", work best for something like that? Do I really need to set up a testing platform for them and test each one out? That's just one example, though. Perhaps we need to work up some very broad and general guidelines on what "testing" means, and apply that to ~arch. >> 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. I've been running ~arch for years and very rarely, do I see a breakage. We're not one of the BSDs, or even Debian, in which we maintain a static branch of specific package versions. In a way, I view "arch" to imply something very close to FreeBSD's -RELEASE branch, just with the flexibility of getting new major revisions periodically. "~arch" is more like -STABLE, but it moves faster and potentially introduces minor breakages once in a while, but nothing that requires a complete reinstall. We don't really have anything that's like -CURRENT or a nightly-like build, in which major, massive breakages are more common. TBH, I don't know if we should have something like that. The hybrid-like approach we have now seems to work out best for us. >> 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? We probably just need to step up review and cleaning out of package.mask more often. Since Portage tools can parse the file already, it shouldn't be too hard to determine if there are any masks in there for packages or package versions that no longer exist in the tree and prune it down some. > 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. Perhaps some periodic, automated reminders to anyone who adds a package to package.mask to check up on it? If the mask persists for a while after such a notification, it escalates to QA or to -dev? -- Joshua Kinard Gentoo/MIPS kumba@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic