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: > http://www.gentoo.org/proj/en/council/meeting-logs/20090528-summary.txt > > 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 policy. The only question here is essentially "at what point do we stop caring about older portage versions". portage 2.1.4.4 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 2.1.4.4 release- specifically "you can't remove eclasses/functionality until 2 years after 2.1.4.4". 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. ~harring
pgp8TE4hNEvfF.pgp
Description: PGP signature
