i actually agree with you
this is about QA, really
what im trying to say is, versioned eclasses have many benefits
and albeit tempted to run my mouth now, i will not spoil it, instead i will go now get with Patrick see that we can define this properly, make everyone understand what we are after, rather than giving examples to illustrate a worst case scenario that further can be misunderstood as what solution we want
it is hard to illustrate what you want to avoid, if there is no solution available, and since others have taken their time to really take apart an example/illustration of worst case scenario and how users could benefit from versioned eclasses (from a technical standpoint, when i had no intention to outline a final say technical solution) i wont make the mistake to further illustrate that, until a solution sound and presentable is found
thank you for your input, you have no idea how much i indeed agree with you on the QA part and the consequences
Daniel
Chris Gianelloni wrote:
On Wed, 2005-01-19 at 05:34 -0600, Daniel Goller wrote:
if you touch unversioned eclasses you spill from ~arch right into arch w/o much you can do about it, think people who run arch they want to test or use gentoo?
...and you test it locally. You also should *never* make changes to an eclass that will break clients without not only testing the eclass, but also any applications that use that eclass and might break, including fixes to the ebuilds for those applications to allow them to work with the new eclass. Is it that hard to understand that you DO NOT COMMIT things that will break the tree?
Personally, I don't care either way about versioned eclasses. My point stands whether they are versioned or not. Nothing should go into the tree that does not work, and nothing should go into the tree that breaks functionality that did work.
Period.
Those that do not follow these absolute laws of QA should have their developer status questioned.
signature.asc
Description: OpenPGP digital signature
