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 84AE0138010 for ; Fri, 19 Oct 2012 20:47:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1BDB621C0DA; Fri, 19 Oct 2012 20:47:44 +0000 (UTC) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id B1CCF21C0D5 for ; Fri, 19 Oct 2012 20:47:12 +0000 (UTC) Received: by mail-bk0-f53.google.com with SMTP id jg15so347360bkc.40 for ; Fri, 19 Oct 2012 13:47:11 -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 :x-google-sender-auth:message-id:subject:from:to:content-type; bh=+ulNB4CUvaDs0wxVjLUE4qVsGD6I5R8QorE9TGtliM4=; b=lKCtV25TVSg/ype+ImXH4jHyYwfMnCM2TveKo4CyhX9opmxeRI3wZgOZKDYpOQ+Tjh 82emzJ1XkXlNHY3hUJZl6xIT+yuC++VC06rfDHJ3eklL6K9uQfwJlPIG8cBmoT3mQGWW DkNwYp36rBdQaSePqnKNvfmdUYaFS+xw0zPZVwftYott1cpqCY+eZzIOw1tviwXkvbwW ysawJOfhurnot7h1JAKFrIjc1+chKn6BifkHWtX+U/nuLuW9QHY6GaKqN0tYmH5ThsZE b5lphRO7pWeY7zqS5DqqOM8VEoDQX3m8x3bPhcfg3b7XKlo4jOrxEeWkTCkragzpil0i wejw== 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 Received: by 10.204.149.2 with SMTP id r2mr831835bkv.0.1350679631735; Fri, 19 Oct 2012 13:47:11 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.204.156.147 with HTTP; Fri, 19 Oct 2012 13:47:11 -0700 (PDT) In-Reply-To: <5081BA9E.2080907@gentoo.org> References: <20121012125315.33500bbb@sera-17.lan> <20121012211023.592e82a1@gentoo.org> <20121013082820.75d280a1@sera-17.lan> <20121016234230.3b79a2fe@gentoo.org> <1350495278.2447.33.camel@belkin4> <20121017220707.02c6f5ac@gentoo.org> <1350575341.2447.40.camel@belkin4> <1350587136.2447.47.camel@belkin4> <1350667312.12879.11.camel@belkin4> <20121019145105.4927316b@gentoo.org> <1350670155.12879.22.camel@belkin4> <20121019154733.31b2284c@gentoo.org> <1350675125.12879.44.camel@belkin4> <5081AD7B.1040100@gentoo.org> <1350676398.12879.50.camel@belkin4> <5081BA9E.2080907@gentoo.org> Date: Fri, 19 Oct 2012 16:47:11 -0400 X-Google-Sender-Auth: PMCJR84Va5Jv2PbFleFvM9MRgv4 Message-ID: Subject: Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages. From: Rich Freeman To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 44316d24-ae80-48c0-ba81-14b086f94e6f X-Archives-Hash: e977839b451c120ed94a8b55023bcff7 On Fri, Oct 19, 2012 at 4:39 PM, Thomas Sachau wrote: > This is not about "having problems with handling eapi-X", this is just > about limited time and the choice where to spend that time. If you do > just a version bump, you often dont have to touch the ebuild at all, > just copy, test, commit and be happy. If you additionally require an > EAPI bump, this means to carefully check the ebuild, adjust it to the > new EAPI and additionally check, that the expected haviour is also the > one that happens. While doing this, i could also have fixed another bug > or have done another version bump. Or, more likely, you probably would just ignore the bug that requires an EAPI bump and leave the existing buggy version in the tree. Then you'd go work on something where your time could be more effectively spent. I've seen this at work all the time - "raising the bar" on quality (as measured by the pound of paperwork) often results in a lower quality system, because fixing bugs is much more expensive so bugs simply don't get fixed. Somebody raised the issue of slot dependencies earlier. I'm completely for a policy that states that the entire tree should be updated to take advantage of these where applicable. I wouldn't state it in terms of EAPI - I'd state it in terms of outcome. Make it a general call for action, and then after so much time have bugs filed when packages do not comply. I'd love to see Gentoo reach a point soon where users don't have to run revdep-rebuild. Focusing on outcomes is what I'm all about - forget about EAPIs - focus on what it is that we really want, and make those things that really matter. Rich