On Sun, 2005-01-23 at 18:31 +0100, Malte S. Stretz wrote: > No, I won't excuse you but quote your sentence following on the one above > "If we are forced to make changes that could break the tree, then we change > the affected packages and revision bump it after doing extensive testing." > > My whole posting was about that latter case and I doubt that you do > "extensive testing" on all versions of the ebuild which is still in the > tree. If you don't ever do interface-changing changes (including removal > of helper routines) then everything is fine. But if you ever need to do > so, you've got to create a new eclass which is more or less some kind of > versioning.
So your problem is that you do not believe that I do extensive testing? Well, I cannot change your opinion, but I can give you my word that I do. I can also give you my track record. Find a single time since I began as a developer where I have made an eclass change that broke the tree. Creating a new eclass has nothing to do with versioning, which is my entire point. I can make an eclass called foo and an eclass called bar, and never shall the two meet. I don't have to create a foo-1 and foo-2 to get this effect. Trying to create a policy wherein developers are required to make version bumps to eclasses forces developers to waste countless hours of time, is counterproductive, and so far has not given a single bit of technical merit as to why it should be done, only some mystical hope that magically all errors are going to disappear because we decided to append a -1 to the name of an eclass. > > Eclasses can never be removed from the tree. This is a fundamental > > truth of the current way things are done. [...] > > Even fundamental truths can change when time and code comes. So now we should start changing our practices in the off chance that eventually, somewhere, someone will write contradictory code? I'm sorry, but I live in the present and I have better things to do with my time than worry about the possibility of someone someday breaking what I write now. It has to work now, which happens to fit in quite nicely with portage's behavior. -- Chris Gianelloni Release Engineering - Operations/QA Manager Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
