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----- |