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 07:47:24PM +0300, Petteri RRRty wrote:
> On 07/11/2010 07:37 PM, Jorge Manuel B. S. Vicetto wrote:
> >> 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.
> Original rules (as they were when I joined 2005):
> You are only allowed to add to the public API of an eclass.
> Eclass removal addition:
> Since then council has approved the ability to fully remove eclasses:
> Under discussion:
> Extend the rules to allow developers to remove functions from the API of
> an eclass. To me this seem exactly like: "The council's purpose is to
> help decide between different technical solutions and encourage people
> to move forward on one unified path."
From my stance, I firmly believe the council doesn't really need to be
involved here. This is QA's domain- specifically to decide tree
The only question here is essentially "at what point do we stop
caring about older portage versions". portage 184.108.40.206 went stable
(carrying that support) 06/01/08. Frankly I'd argue the council's
original decision while bound to eclasses, should've been bound to the
220.127.116.11 release- specifically "you can't remove eclasses/functionality
until 2 years after 18.104.22.168".
So... I firmly view this as QA's domain (they set the rules for most
other tree policies). Leave it to them to decide. I realize from
the standpoint of following the rules, this will require the council
to state "yeah, we're backing out of this, it's now QA's domain", but
this is my view on what should be done.