Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others
Date: Sun, 11 Jul 2010 21:35:39
Message-Id: 20100711213322.GB6598@hrair
In Reply to: Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others by "Petteri Räty"
1 On Sun, Jul 11, 2010 at 07:47:24PM +0300, Petteri RRRty wrote:
2 > On 07/11/2010 07:37 PM, Jorge Manuel B. S. Vicetto wrote:
3 >
4 > >
5 > >> Simply put, the council's purpose is not to say "oh we have to stop
6 > >> development and have a 4 week debate about everything minor". The
7 > >> council's purpose is to help decide between different technical
8 > >> solutions and encourage people to move forward on one unified path.
9 > >> The council's purpose is not to HINDER development as your responses
10 > >> clearly suggest you would like to hinder eclass development but
11 > >> instead to promote positive development.
12 > >
13 >
14 > Original rules (as they were when I joined 2005):
15 >
16 > You are only allowed to add to the public API of an eclass.
17 >
18 > Eclass removal addition:
19 >
20 > Since then council has approved the ability to fully remove eclasses:
21 > http://www.gentoo.org/proj/en/council/meeting-logs/20090528-summary.txt
22 >
23 > Under discussion:
24 >
25 > Extend the rules to allow developers to remove functions from the API of
26 > an eclass. To me this seem exactly like: "The council's purpose is to
27 > help decide between different technical solutions and encourage people
28 > to move forward on one unified path."
29
30 From my stance, I firmly believe the council doesn't really need to be
31 involved here. This is QA's domain- specifically to decide tree
32 policy.
33
34 The only question here is essentially "at what point do we stop
35 caring about older portage versions". portage 2.1.4.4 went stable
36 (carrying that support) 06/01/08. Frankly I'd argue the council's
37 original decision while bound to eclasses, should've been bound to the
38 2.1.4.4 release- specifically "you can't remove eclasses/functionality
39 until 2 years after 2.1.4.4".
40
41 So... I firmly view this as QA's domain (they set the rules for most
42 other tree policies). Leave it to them to decide. I realize from
43 the standpoint of following the rules, this will require the council
44 to state "yeah, we're backing out of this, it's now QA's domain", but
45 this is my view on what should be done.
46
47 ~harring