List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Sun, Jul 11, 2010 at 7:49 AM, Petteri Räty <firstname.lastname@example.org> wrote:
> On 07/11/2010 08:02 AM, Doug Goldstein wrote:
>> If I really need to go to the council with every change, considering
>> it must be debated on the ML for at least X number of days prior to
>> going to the council, I'd more likely just remove MythTV from the tree
>> and maintain it in an overlay. I don't invest a lot of time in the
>> MythTV ebuilds, but they work for a large majority of people. And when
>> a new version comes out it requires some retooling and it just works
>> for everyone.
> When someone proposes this I'll let you know. What's under discussion is
> allowing removals to the public API of eclasses by following a
> documented process (that doesn't involve council approval).
>> So basically, you guys decide.. am I pulling them out of the tree or
>> am I leaving them in?
> If you decided to drop maintenance of MythTV in main tree, wouldn't it
> be a better service to users to try and find a new maintainer (who would
> possibly merge stuff from your overlay)?
Simply put, the council's purpose is not to say "oh we have to stop
development and have a 4 week debate about everything minor". The
council's purpose is to help decide between different technical
solutions and encourage people to move forward on one unified path.
The council's purpose is not to HINDER development as your responses
clearly suggest you would like to hinder eclass development but
instead to promote positive development.
Someone along the years the council lost its way and has felt that it
needs to stick its fingers into places that it really doesn't belong.
Its really become like the upper management at a large company that
slows its developers down, instead of helping make them more