Re: [gentoo-dev] [RFC] Tightening EAPI rules

On 10/02/2014 22:56, Alec Warner wrote: > On Mon, Feb 10, 2014 at 8:26 AM, Alan McKinnon > wrote: > > On 10/02/2014 18:05, Ulrich Mueller wrote: > >> Removing support for it from a package manager should of course > >> > happen much later (well after it

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, Feb 10, 2014 at 8:26 AM, Alan McKinnon wrote: > On 10/02/2014 18:05, Ulrich Mueller wrote: > >> Removing support for it from a package manager should of course > >> > happen much later (well after it is banned). > > The package manager must be able to uninstall old packages, which > > esse

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 21:46:56 +0800 Patrick Lauer wrote: >On 02/10/2014 09:23 PM, Anthony G. Basile wrote: >> The statement "Deprecating an EAPI can mean breakage" depends on >> what we mean by "deprecating." I'm assuming here we mean something >> like repoman won't allow commits at EAPI=1,2,3 but

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, Feb 10, 2014 at 12:20 PM, Tom Wijsman wrote: > On Mon, 10 Feb 2014 17:05:22 +0100 > Ulrich Mueller wrote: >> The package manager must be able to uninstall old packages, which >> essentially means that support for old EAPIs cannot be removed. > > That's only a subset of the entire EAPI, wh

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 17:05:22 +0100 Ulrich Mueller wrote: > > On Mon, 10 Feb 2014, Rich Freeman wrote: > > > On Mon, Feb 10, 2014 at 10:31 AM, Ulrich Mueller > > wrote: > >> I'd rather argue in terms of time instead of version numbers, > >> because of the upgrade path for old systems. We gua

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 16:16:42 + Ciaran McCreesh wrote: > > From my limited look at the code I've done so far in the small bit > > of repoman work on the Portage team, as detailed in another mail I > > just sent to you on this ML, I wouldn't consider it as a problem > > just now. > > > > We fo

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On 10/02/2014 18:05, Ulrich Mueller wrote: >> Removing support for it from a package manager should of course >> > happen much later (well after it is banned). > The package manager must be able to uninstall old packages, which > essentially means that support for old EAPIs cannot be removed. I f

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 15:58:23 +0100 Tom Wijsman wrote: > On Mon, 10 Feb 2014 09:41:13 -0500 > Rich Freeman wrote: > > On Mon, Feb 10, 2014 at 9:23 AM, Tom Wijsman > > wrote: > > > Well, that package maintainers are called developers on Gentoo > > > isn't helping the interpretation here; regardles

Re: [gentoo-dev] [RFC] Tightening EAPI rules

> On Mon, 10 Feb 2014, Rich Freeman wrote: > On Mon, Feb 10, 2014 at 10:31 AM, Ulrich Mueller > wrote: >> I'd rather argue in terms of time instead of version numbers, >> because of the upgrade path for old systems. We guarantee one year >> for stable systems, but IMHO we should be more conse

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, Feb 10, 2014 at 10:31 AM, Ulrich Mueller wrote: > I'd rather argue in terms of time instead of version numbers, because > of the upgrade path for old systems. We guarantee one year for stable > systems, but IMHO we should be more conservative for EAPI deprecation > and go for two or three

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On 02/10/2014 09:35 AM, Tom Wijsman wrote: one and possibly needed features. You will connect the question of >"are we ready to deprecate X" with the question "we need to introduce >Y for needed features a, b and c." It is hard to grasp for me for when features from a newer EAPI would delay the

Re: [gentoo-dev] [RFC] Tightening EAPI rules

> On Mon, 10 Feb 2014, Patrick Lauer wrote: > On 02/10/2014 09:23 PM, Anthony G. Basile wrote: >> I think we should look at the question of deprecating EAPI's on and >> ad hoc basis with discussion on the list and a vote in the council. +1 > I think it's safe to deprecate the antepenultimate

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 08:34:00 -0500 Rich Freeman wrote: > On Mon, Feb 10, 2014 at 7:43 AM, Patrick Lauer > wrote: > > Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal) > > Does "adding" in this case include revbumps? Yes; though, we kind of expect rev bumps to include multiple fixes if

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 09:41:13 -0500 Rich Freeman wrote: > On Mon, Feb 10, 2014 at 9:23 AM, Tom Wijsman > wrote: > > Well, that package maintainers are called developers on Gentoo isn't > > helping the interpretation here; regardless of how one defines > > those, both maintainers and PM implemente

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, Feb 10, 2014 at 9:23 AM, Tom Wijsman wrote: > Well, that package maintainers are called developers on Gentoo isn't > helping the interpretation here; regardless of how one defines those, > both maintainers and PM implementers have to be taken into account here. > > From quick thoughts the

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 08:23:51 -0500 "Anthony G. Basile" wrote: > On 02/10/2014 07:43 AM, Patrick Lauer wrote: > > EAPI 4 becomes deprecated when/if there's a new EAPI allowed in-tree > > (EAPI 6, most likely) > > I am concerned about making this a "rule". Maybe rather a rule with exceptions, or

Re: [gentoo-dev] [RFC] Tightening EAPI rules

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/02/14 08:46 AM, Patrick Lauer wrote: > On 02/10/2014 09:23 PM, Anthony G. Basile wrote: >> The statement "Deprecating an EAPI can mean breakage" depends on >> what we mean by "deprecating." I'm assuming here we mean >> something like repoman w

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 14:24:39 +0100 Dirkjan Ochtman wrote: > On Mon, Feb 10, 2014 at 2:21 PM, Tom Wijsman > wrote: > > Apart from that, they however sit in the way of deprecating support > > for that EAPI; at one point it becomes tedious to have to support > > 10 EAPIs in our code (eg. Portage),

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, Feb 10, 2014 at 8:46 AM, Patrick Lauer wrote: > I think it's safe to deprecate the antepenultimate EAPI, and then do the > banning on a more delayed and controlled basis. Yeah, I don't think we need to overly debate deprecation, other than in corner cases like the toolchain (just that min

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On 02/10/2014 09:23 PM, Anthony G. Basile wrote: > The statement "Deprecating an EAPI can mean breakage" depends on what we > mean by "deprecating." I'm assuming here we mean something like repoman > won't allow commits at EAPI=1,2,3 but that ebuilds in the tree at those > EAPI's will continue wor

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On 02/10/2014 09:34 PM, Rich Freeman wrote: > On Mon, Feb 10, 2014 at 7:43 AM, Patrick Lauer wrote: >> Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal) > > Does "adding" in this case include revbumps? By the design of our repo structure and repoman, yes. (I don't see a clean way around

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, Feb 10, 2014 at 7:43 AM, Patrick Lauer wrote: > Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal) Does "adding" in this case include revbumps? > More than two supported EAPIs is an unneeded burden on developers. Is this really a generally held belief? I don't find it a burden t

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, Feb 10, 2014 at 2:21 PM, Tom Wijsman wrote: > Apart from that, they however sit in the way of deprecating support for > that EAPI; at one point it becomes tedious to have to support 10 EAPIs > in our code (eg. Portage), hence we should aim to deprecate versions of > a few years old. Keepin

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On 02/10/2014 07:43 AM, Patrick Lauer wrote: EAPI 4 becomes deprecated when/if there's a new EAPI allowed in-tree (EAPI 6, most likely) I am concerned about making this a "rule". While I think its okay for the 4/5/6 move, I'm not sure if it will always be a good idea. 1) "Deprecating" an EAP

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 14:03:49 +0100 Dirkjan Ochtman wrote: > On Mon, Feb 10, 2014 at 1:43 PM, Patrick Lauer > wrote: > > The daily updated stats [2] show a slow general trend down. > > There's historical data (well, just a few days right now at [3] > > What are you looking at here? .ebuild files

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, Feb 10, 2014 at 1:43 PM, Patrick Lauer wrote: > The daily updated stats [2] show a slow general trend down. > There's historical data (well, just a few days right now at [3] What are you looking at here? .ebuild files in the tree? Or latest version per-package? Old EAPI versions are obvi

[gentoo-dev] [RFC] Tightening EAPI rules

As previously discussed I would like to suggest that the number of tolerated EAPIs be reduced. There's been some discussion over the last 2+ years, with a weak consensus towards deprecating some EAPIs. What, when and how still isn't decided. So let's add some data so we have a better idea: EAPI St