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 6C85A138010 for ; Wed, 3 Apr 2013 09:32:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E94C0E0D4F; Wed, 3 Apr 2013 09:32:38 +0000 (UTC) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 30085E0D49 for ; Wed, 3 Apr 2013 09:32:37 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id d41so580578eek.22 for ; Wed, 03 Apr 2013 02:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gfqrt8aKtTf4GqCYQKlIjWRGKyDLrxdCl4wgS4lq3jE=; b=n/eL0XYzO+4LfgW6r6xo+5/tzivIyLD6i9fq57YNS5C43rVweUgy7V5PoJx4t3g11S WnxneOVQOmPSTfBIdbUHrWvdaa2fp/FwA2wEBAEQx4eCPRQFoB/iIO0WpPuv+jEpGLSs LmcKufRx9nSHPAHREMqLVNe6tT6XI6eXROtmW2aJkpdSQAgd16JB3MYjEzvbenBPww3W eQvIISlFSHIsIpQwY8f2xqodj4WkXzApxtUCEJU984GqlRC1OyuGaaIBl3cRNpOcZWS0 zwTk/bFSVQcnIw5fRJEtSTHx55cURoczAnVKO1aQtkHEOwy26KysdHwEF+cMQeOhJQNV bnJg== X-Received: by 10.14.111.72 with SMTP id v48mr2199794eeg.11.1364981556567; Wed, 03 Apr 2013 02:32:36 -0700 (PDT) Received: from [192.168.4.18] ([5.157.117.94]) by mx.google.com with ESMTPS id r4sm7015143eeo.12.2013.04.03.02.32.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 02:32:35 -0700 (PDT) Message-ID: <515BF6FD.6080301@gmail.com> Date: Wed, 03 Apr 2013 11:31:41 +0200 From: "vivo75@gmail.com" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130310 Thunderbird/17.0.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 To: gentoo-project@lists.gentoo.org CC: Ralph Sennhauser Subject: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09 References: <20817.55135.354752.397336@a1i15.kph.uni-mainz.de> <20826.59983.990551.148156@a1i15.kph.uni-mainz.de> <20130403110754.41276e21@sera-20.lan> In-Reply-To: <20130403110754.41276e21@sera-20.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 11f1dc4e-2306-4642-b146-f0361cf6da4c X-Archives-Hash: fdbdb4225be91529b18eabf6319b4e5f Il 03/04/2013 11:07, Ralph Sennhauser ha scritto: > On Tue, 2 Apr 2013 16:31:51 +0100 > Markos Chandras wrote: > >>> Should we have a stricter rule? Would such a rule help significantly >>> reducing the number of EAPI 0 ebuilds? >> I believe so. Maybe make repoman scream if you commit an ebuild with >> 1<=EAPI<=4 ? > I feel strongly against starting with anything but EAPI 0. And I > don't consider EAPI 4 old enough to start pestering maintainers about > it. > > What we need is a live cycle of EAPIs to keep things manageable in the > long run. We aren't under pressure to get rid of as many as possible > ASAP. A simple scheme could be > > - EAPI becomes second latest > - 5 years later repoman warns. > - 2 years later repoman errors out. > > With that scheme EAPI=0 would be due soon. As the "bump to latest > eapi" policy isn't that old and seems to have only sunk in a about a > year ago, and the myth of still requiring system packages to be EAPI=0 > kept a lot of the tree at EAPI=0 for a long time. Fact is EAPI 0 ebuilds > are still many, though the number started to crumble significantly > lately. So waiting another year before starting actively warn might be > appropriate. > > The important thing is for the council to declare intent and timeframe, > so maintainers can plan far ahead. The other thing that became apparent > from last discussion is that a slightly low EAPI shouldn't be a card > blanch for zealots to touch packages they don't maintain or to file > bugs about it. > Hopefully the council will keep in mind that today it's not possible to upgrade portage if the system is old enough to require an update from python-2.6.5-r2 => :2.7, at least not with a lot of trickery with --nodeps and (much more) equally ugly stuff. python-2.6.5-r2 is dated 01 May 2010 in ChangeLog. 3 years are pratically more than you can ever hope to support without adding manpower dedicated to keep backward compatibility. Previous reasoning based on the assumption that a) newer api are better b) less of them is better c) not being able to upgrade portage mean a not upgradable/modifiable gentoo install.