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 C4B42138010 for ; Fri, 31 Aug 2012 12:15:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D45A8E04EC; Fri, 31 Aug 2012 12:15:19 +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 87C72E04C1 for ; Fri, 31 Aug 2012 12:14:29 +0000 (UTC) Received: by bkwj4 with SMTP id j4so1291949bkw.40 for ; Fri, 31 Aug 2012 05:14: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 :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Tcrqresfw7FH6RKc/wtThUdrKs5Rsij5UK3YPXwj/WU=; b=Ejw4ZBRMYGgIm6v5beXNcp47YAIM3PtEuu3sewcoe8i18UGy9ZYhII0+vE5KUMOQ+D 0j+RBB67S1KnNT8+7App1Q7OFQQ3tmJMVeFDuBWHDLd2esJg8ineFffkFQtA7h5Ovs+Z NkGeday8evmuqlFNECkDj8tFMhl+IZMUYG4RNm/j+3XunVsKVcoSTqPFCNK/B6fpebZP 2z/0GDf+BKgeDkHcxfiUvZ+KDz/5CggN4NgS6/9LogQuBAdxcWwUPOW3TJN0TBSgyG4i mMmcttoUGobBCpwFyNxK/exiXLqum5Z7+UaPGQD/s1mnplTO06CiQxq1ckjzC/Wp2NN2 U3wg== 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.129.8 with SMTP id m8mr3977739bks.62.1346415268409; Fri, 31 Aug 2012 05:14:28 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.204.14.76 with HTTP; Fri, 31 Aug 2012 05:14:28 -0700 (PDT) In-Reply-To: <201208311103.19398.dilfridge@gentoo.org> References: <1650487.RNHkTcOSMI@elia> <201208311103.19398.dilfridge@gentoo.org> Date: Fri, 31 Aug 2012 08:14:28 -0400 X-Google-Sender-Auth: nFzUn-D5KMnfdNbWelTOGGvZ06I Message-ID: Subject: Re: [gentoo-dev] EAPI usage From: Rich Freeman To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 7e85fafb-c21f-42f3-b397-16461cab712e X-Archives-Hash: 3629cbfea5d736ae4ebff69596f739e4 On Fri, Aug 31, 2012 at 5:03 AM, Andreas K. Huettel wrote: > > Let's say, we as in Gentoo decide that we're completely sick of keeping all > that old code out there adjusted to newer and newer gcc versions that are more > and more critical towards minor details of the c++ standards. So, we declare > that gcc-4.5 has to be enough for everyone, we'll just keep it in tree forever > and dont bother anymore with all these superfluous "does not build with > gcc-4.7" bugs. That is not an appropriate analogy, as I'm not suggesting that we refuse to support newer EAPIs. I'm just saying that packages shouldn't be bumped just for the sake of bumping them. > > Give me one non-trivial ebuild where you can absolutely guarantee that a bump > from EAPI=0 to EAPI=4 will not enable any improvements (in readability, > failsafe behaviour and code size for example). Suppose for the sake of argument that no such ebuild exists. I still maintain that there is little benefit from forcing an EAPI bump on new ebuilds. If I thought that bumping the EAPI would make my life as a maintainer easier I'd just do it - I wouldn't need a policy to tell me to do it. The only reason you'd need a policy is if I as a maintainer figured that bumping the EAPI was more hassle than whatever benefits I get down the road from all those improvements. If I did think that bumping the EAPI wasn't worth the hassle, and yet I was told that I'd be banned as a dev for not doing so anyway, then obviously I'm going to do the minimum necessary to comply with policy, which means changing the EAPI line of the ebuild and only changing other lines as required to get the thing to build and comply with PMS. So, while all those benefits you named are "enabled" few would actually be realized. > > Last point, if someday the tree contains ebuilds with 7-8 different EAPI's, > we'll have succeeded in generating an unmaintainable mess (tm). It will not be > any fun to look up things in PMS anew everytime you edit something. I suspect that most devs just edit things that they maintain, and that means that they can control how many EAPIs are in use in those ebuilds. Again, devs already have incentive to make their own lives earlier - we don't need to turn that into policy. I might see some benefit for devs who routinely modify stuff that they don't maintain, but that should generally be kept to a minimum anyway. If unsure how how to edit any particular ebuild, just file a bug! And if the package isn't maintained, then nobody will be bumping its EAPI anyway. Rich