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 6508F138010 for ; Tue, 4 Sep 2012 21:10:21 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 67ECFE05FA; Tue, 4 Sep 2012 21:09:12 +0000 (UTC) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 52E1BE06B4 for ; Tue, 4 Sep 2012 21:06:23 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so10788836pbb.40 for ; Tue, 04 Sep 2012 14:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=j6MiLZHu4IoC3EUyOkq8RVzdqJ18kBXCPg42xiu/Kow=; b=qJeEUqtniRJKCilfx1eEWkQXZ+fwDgrMo6sezg/39PDBVCcNIRiIc8X+a6y8iTdYGk Efi5u/K+mmFstYI3hbVycpl05SnSQ7tX9ugS/JcYEnMTPTez1rW+wCboJ8z3OjmxXJpx vgQGk8Q5NaXYBYkaMYb7qbmikRF82FpbW5cHypltO6edrZ6dAC3PESvlDajfk4RtBCws h/hxdoCuPx/ntGc6lhuw3lErKIOkzIXM44/CF3y2FCxdGpznpSZ6wbxs4d+qAM6xDmBj Ii5/GNxhyLZjYvqr89+pPYUPXgk77psvO/LjHYE9ATc27OaaM8O3A1AdDDSywxBPCxtW PYjA== Received: by 10.66.78.195 with SMTP id d3mr43864174pax.17.1346792782620; Tue, 04 Sep 2012 14:06:22 -0700 (PDT) Received: from smtp.gmail.com:587 (74-95-192-101-SFBA.hfc.comcastbusiness.net. [74.95.192.101]) by mx.google.com with ESMTPS id oc2sm12922401pbb.69.2012.09.04.14.06.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 14:06:20 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Tue, 04 Sep 2012 14:06:19 -0700 Date: Tue, 4 Sep 2012 14:06:19 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] EAPI usage Message-ID: <20120904210619.GA18495@localhost> References: <1650487.RNHkTcOSMI@elia> <201208311103.19398.dilfridge@gentoo.org> <201209021510.55447.dilfridge@gentoo.org> <50436EDD.3030109@orlitzky.com> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50436EDD.3030109@orlitzky.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 3c0ee104-1892-4d8c-887d-30cc752cc30c X-Archives-Hash: 6ba1ddbfea024211f4dacfc0b11067c4 On Sun, Sep 02, 2012 at 10:36:13AM -0400, Michael Orlitzky wrote: > On 09/02/2012 09:46 AM, Rich Freeman wrote: > > On Sun, Sep 2, 2012 at 9:10 AM, Andreas K. Huettel wrote: > >> What I dont actually understand at all is why bumping the EAPI should be so > >> complicated or involved that it even deserves so much resistance... > > > > Ok, it REALLY annoys me when people pull out this kind of a line > > in an argument... If it isn't all that complicated or involved and it > > just makes so much sense, then why do we bother to waste time asking > > for it to be made policy, since obviously everybody will just do it > > anyway... > > > > Believe it or not, people who take up an opposing side in a debate > > don't ALWAYS do it because they're simply dumber than you. That is, > > unless they're arguing with me... :) > > > > > I think everyone would be happier if all ebuilds in the tree were EAPI4. > On the other hand, Rich is right that making this a policy will have the > opposite of the intended effect: developers just won't fix bugs in > EAPI<4 ebuilds when they don't have time to do the EAPI bump (one could > easily spend a few hours on this). > > As a compromise, it could be made policy that "bump to EAPI=foo" bugs > are valid. If someone would benefit from such a bump, he can file a bug > and know that it won't be closed WONTFIX. On the other hand, the dev is > under no more pressure than usual to do the bump. If you attach a patch and have done the legwork, sure. If you're just opening bugs w/ "bump to EAPI=monkeys", bluntly, it's noise and it's annoying. EAPI bump requests for pkgs that need to move forward so an eclass can be cleaned up/moved forward, sure, but arbitrary "please go bump xyz" without a specific reason (and/or legwork done if not) isn't helpful. Kind of equivalent to zero-day bump requests in my view in terms of usefulness. ~harring