1 |
On Sun, Jul 11, 2010 at 7:49 AM, Petteri Räty <betelgeuse@g.o> wrote: |
2 |
> On 07/11/2010 08:02 AM, Doug Goldstein wrote: |
3 |
> |
4 |
>> If I really need to go to the council with every change, considering |
5 |
>> it must be debated on the ML for at least X number of days prior to |
6 |
>> going to the council, I'd more likely just remove MythTV from the tree |
7 |
>> and maintain it in an overlay. I don't invest a lot of time in the |
8 |
>> MythTV ebuilds, but they work for a large majority of people. And when |
9 |
>> a new version comes out it requires some retooling and it just works |
10 |
>> for everyone. |
11 |
>> |
12 |
> |
13 |
> When someone proposes this I'll let you know. What's under discussion is |
14 |
> allowing removals to the public API of eclasses by following a |
15 |
> documented process (that doesn't involve council approval). |
16 |
> |
17 |
>> So basically, you guys decide.. am I pulling them out of the tree or |
18 |
>> am I leaving them in? |
19 |
>> |
20 |
> |
21 |
> If you decided to drop maintenance of MythTV in main tree, wouldn't it |
22 |
> be a better service to users to try and find a new maintainer (who would |
23 |
> possibly merge stuff from your overlay)? |
24 |
> |
25 |
> Regards, |
26 |
> Petteri |
27 |
> |
28 |
> |
29 |
|
30 |
Simply put, the council's purpose is not to say "oh we have to stop |
31 |
development and have a 4 week debate about everything minor". The |
32 |
council's purpose is to help decide between different technical |
33 |
solutions and encourage people to move forward on one unified path. |
34 |
The council's purpose is not to HINDER development as your responses |
35 |
clearly suggest you would like to hinder eclass development but |
36 |
instead to promote positive development. |
37 |
|
38 |
Someone along the years the council lost its way and has felt that it |
39 |
needs to stick its fingers into places that it really doesn't belong. |
40 |
Its really become like the upper management at a large company that |
41 |
slows its developers down, instead of helping make them more |
42 |
efficient. |
43 |
|
44 |
-- |
45 |
Doug Goldstein |