| 1 |
On Sun, Jul 11, 2010 at 11:37 AM, Jorge Manuel B. S. Vicetto |
| 2 |
<jmbsvicetto@g.o> wrote: |
| 3 |
> -----BEGIN PGP SIGNED MESSAGE----- |
| 4 |
> Hash: SHA1 |
| 5 |
> |
| 6 |
> Hi Doug. |
| 7 |
> |
| 8 |
> On 11-07-2010 16:03, Doug Goldstein wrote: |
| 9 |
>> On Sun, Jul 11, 2010 at 7:49 AM, Petteri Räty <betelgeuse@g.o> wrote: |
| 10 |
>>> On 07/11/2010 08:02 AM, Doug Goldstein wrote: |
| 11 |
>>> |
| 12 |
>>>> If I really need to go to the council with every change, considering |
| 13 |
>>>> it must be debated on the ML for at least X number of days prior to |
| 14 |
>>>> going to the council, I'd more likely just remove MythTV from the tree |
| 15 |
>>>> and maintain it in an overlay. I don't invest a lot of time in the |
| 16 |
>>>> MythTV ebuilds, but they work for a large majority of people. And when |
| 17 |
>>>> a new version comes out it requires some retooling and it just works |
| 18 |
>>>> for everyone. |
| 19 |
>>>> |
| 20 |
>>> |
| 21 |
>>> When someone proposes this I'll let you know. What's under discussion is |
| 22 |
>>> allowing removals to the public API of eclasses by following a |
| 23 |
>>> documented process (that doesn't involve council approval). |
| 24 |
>>> |
| 25 |
>>>> So basically, you guys decide.. am I pulling them out of the tree or |
| 26 |
>>>> am I leaving them in? |
| 27 |
>>>> |
| 28 |
>>> |
| 29 |
>>> If you decided to drop maintenance of MythTV in main tree, wouldn't it |
| 30 |
>>> be a better service to users to try and find a new maintainer (who would |
| 31 |
>>> possibly merge stuff from your overlay)? |
| 32 |
>>> |
| 33 |
>>> Regards, |
| 34 |
>>> Petteri |
| 35 |
>>> |
| 36 |
>>> |
| 37 |
>> |
| 38 |
>> Simply put, the council's purpose is not to say "oh we have to stop |
| 39 |
>> development and have a 4 week debate about everything minor". The |
| 40 |
>> council's purpose is to help decide between different technical |
| 41 |
>> solutions and encourage people to move forward on one unified path. |
| 42 |
>> The council's purpose is not to HINDER development as your responses |
| 43 |
>> clearly suggest you would like to hinder eclass development but |
| 44 |
>> instead to promote positive development. |
| 45 |
> |
| 46 |
> There seems to be some misunderstanding going on as we (Gentoo) haven't |
| 47 |
> approved (in prior councils terms or in the current one which hopes to |
| 48 |
> have its first meeting in the coming week or the following) any rules |
| 49 |
> about eclass changes having to be discussed or approved by the council. |
| 50 |
> |
| 51 |
>> Someone along the years the council lost its way and has felt that it |
| 52 |
>> needs to stick its fingers into places that it really doesn't belong. |
| 53 |
>> Its really become like the upper management at a large company that |
| 54 |
>> slows its developers down, instead of helping make them more |
| 55 |
>> efficient. |
| 56 |
> |
| 57 |
> About the issue in discussion, Petteri was recalling that contrary to |
| 58 |
> what anyone new to Gentoo might conclude from the current discussion, |
| 59 |
> the issue of eclass deprecation has been subject to at least 2 separate |
| 60 |
> discussions in the past 2 or 3 years and that in the last round there |
| 61 |
> was a proposal for setting minimal deprecation time frames. |
| 62 |
> |
| 63 |
> - -- |
| 64 |
> Regards, |
| 65 |
> |
| 66 |
> Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org |
| 67 |
> Gentoo- forums / Userrel / Devrel / KDE / Elections |
| 68 |
|
| 69 |
Jorge, |
| 70 |
|
| 71 |
I remember very clearly as you and I were both council members at the |
| 72 |
time. My point is that this discussion does not need to even happen |
| 73 |
and the council shouldn't even remotely be involved here. |
| 74 |
|
| 75 |
Let developers develop. |
| 76 |
|
| 77 |
-- |
| 78 |
Doug Goldstein |
Archives