Gentoo Archives: gentoo-dev

From: "Jorge Manuel B. S. Vicetto" <jmbsvicetto@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others
Date: Sun, 11 Jul 2010 16:38:13
Message-Id: 4C39F356.1090200@gentoo.org
In Reply to: Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others by Doug Goldstein
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA1
3
4 Hi Doug.
5
6 On 11-07-2010 16:03, Doug Goldstein wrote:
7 > On Sun, Jul 11, 2010 at 7:49 AM, Petteri Räty <betelgeuse@g.o> wrote:
8 >> On 07/11/2010 08:02 AM, Doug Goldstein wrote:
9 >>
10 >>> If I really need to go to the council with every change, considering
11 >>> it must be debated on the ML for at least X number of days prior to
12 >>> going to the council, I'd more likely just remove MythTV from the tree
13 >>> and maintain it in an overlay. I don't invest a lot of time in the
14 >>> MythTV ebuilds, but they work for a large majority of people. And when
15 >>> a new version comes out it requires some retooling and it just works
16 >>> for everyone.
17 >>>
18 >>
19 >> When someone proposes this I'll let you know. What's under discussion is
20 >> allowing removals to the public API of eclasses by following a
21 >> documented process (that doesn't involve council approval).
22 >>
23 >>> So basically, you guys decide.. am I pulling them out of the tree or
24 >>> am I leaving them in?
25 >>>
26 >>
27 >> If you decided to drop maintenance of MythTV in main tree, wouldn't it
28 >> be a better service to users to try and find a new maintainer (who would
29 >> possibly merge stuff from your overlay)?
30 >>
31 >> Regards,
32 >> Petteri
33 >>
34 >>
35 >
36 > Simply put, the council's purpose is not to say "oh we have to stop
37 > development and have a 4 week debate about everything minor". The
38 > council's purpose is to help decide between different technical
39 > solutions and encourage people to move forward on one unified path.
40 > The council's purpose is not to HINDER development as your responses
41 > clearly suggest you would like to hinder eclass development but
42 > instead to promote positive development.
43
44 There seems to be some misunderstanding going on as we (Gentoo) haven't
45 approved (in prior councils terms or in the current one which hopes to
46 have its first meeting in the coming week or the following) any rules
47 about eclass changes having to be discussed or approved by the council.
48
49 > Someone along the years the council lost its way and has felt that it
50 > needs to stick its fingers into places that it really doesn't belong.
51 > Its really become like the upper management at a large company that
52 > slows its developers down, instead of helping make them more
53 > efficient.
54
55 About the issue in discussion, Petteri was recalling that contrary to
56 what anyone new to Gentoo might conclude from the current discussion,
57 the issue of eclass deprecation has been subject to at least 2 separate
58 discussions in the past 2 or 3 years and that in the last round there
59 was a proposal for setting minimal deprecation time frames.
60
61 - --
62 Regards,
63
64 Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
65 Gentoo- forums / Userrel / Devrel / KDE / Elections
66 -----BEGIN PGP SIGNATURE-----
67 Version: GnuPG v2.0.15 (GNU/Linux)
68 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
69
70 iQIcBAEBAgAGBQJMOfNWAAoJEC8ZTXQF1qEPsuQP/ApDmnJ8hNybSBzSOack2HIu
71 0IpIPgRV43s6SGLQuZH8sh2Svuzxlx7nMEb5/i+NkFrqnBp0p843onQorN2iO0a4
72 95k6CE23GRIaJKaOuNduAhI6Okme6/dVAaDhHzXRCwke+Sbbeohn8gnvZyu/fb3/
73 M/YTCXsz9Iur6ucs3pGNbE5aakJMwM6Su/h6QB4FjA+J0D9K9oHLf6aC70CKyH+e
74 Tw71UnGsb84lvd7kGsbRNn+RNEkRjvGQNA87y8Pau/q8YEmzH660zyg6tiMwLRnq
75 B1DaHYisVI6v9WAV7pRj6uAHYe52raeAZvFg025JNyo25tRbLpL9x+65lRF+yVVk
76 kc93rCMZsfgCsZoNWDK2QZWSrqYLTUHdbin66eNzxciqWBfoK3plBMp+CDg9iJb3
77 dSKBz2Ixsv5GWm6IcZM9wEzX34Wk+SJlj4ZPiD8iHOFT1kU4G3FmOcrI00ijXM/p
78 dAPMfz82uWFlaRwOMrfMJzq2Uy8SvU+8s68D7LKFUQP2e0xPsbBi6WF9lDPXys80
79 x073GzXDq+MfyQYxn1VLRwXHAhJNKbyGvy0Unm8scKr3+HzTZY8+G4Uvt/OAfg+4
80 YLorgdiRsGm4ecr4Y2DCydMk6TumS/915lmtePmNDdZ+s2lVTGem2cKVc8EJI42z
81 91KjRH4dYEj968oOenST
82 =G61A
83 -----END PGP SIGNATURE-----

Replies