On Sunday 23 January 2005 16:05 CET Chris Gianelloni wrote: > 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?
*argl* no, I don't have any problems at all, neither with you (at least until you didn't say I'm smoking crack) nor with the way eclasses are handled currently. As I said before, I do not want to participate in this discussion, I just noticed some point where your argumentation was flawed and pointed it out. Why is everybody here always jumping the roof as soon as somebody says something which isn't 100% on his own line? Most the time reading gentoo-dev sounds like kindergarten to me. > 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. I can't and my point was *not* at all to attack you personally. With "extensive testing" I doubted in I meant that as soon as you made a bigger change to an eclass which might break the tree you go and try out and build every affected package on every version which is still in the tree (ie. not only HEAD) on every platform available. If you do, fine, I know that I myself wouldn't do so. > 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. Gah, I never said that versioned eclasses would give us world peace. I also didn't say that you should bump the eclass with every one-line change you do, just with changes which affect the interface. I can't see where a version bump maybe once per year costs "countless hours of time", but hey. See it the other way round: Currently the interface of an eclass must not change in a BIC way, ever. So with time you *maybe* carry along a lot of cruft in the files (or maybe not). Just assuming that's the case, with versioned eclasses you'd have a chance to actually change that interface if you think the old one is bad. The old ebuilds will keep their reference to the old eclass and all new ones will start to use the new one. Right, you can do the same if you just rename the eclass to something else, like games.eclass to games-ng.eclass. Or games-1.eclass to games-2.eclass. There's actually not any difference to how its done currently, just that there would be a guideline on how to name the eclasses when a change is needed. And before you start flaming about counterproductive and time-wasting policies please remember that this is only a suggestion, an idea, nothing anybody (me being the last one) want to force down your throat. Calm down, please. > > > 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. Erm... maybe I misread some of the other postings, but nowhere I read that this should be done yesterday. The current way eclasses are handled seems to work pretty well and there's no reason to change that until the code in Portage is available. But there *might* (as in "it's possible, that") be some room for improvements, done at some point in the future. Whatever, I said what I wanted to say (even more than I planned actually) and will watch the flamefest from a safe and cosy place on the peanut gallery again. Cheers, Malte close(STDOUT); -- [email protected] mailing list
