On Sat, 2005-01-22 at 17:53 -0600, Daniel Goller wrote: > all you get is the same interface, the code behind it you dont know > about if you say get a binary only lib, you can check the header to make > sure the interface is still intact, what the underlying code is you dont > know, but you know the lib you got now has version 1.2 while you last > used 1.1, if 1.2 doesnt work (same interface or not) you still have 1.1 > and can revert to that,
Umm... is this not the same as you would get between, say a 1.2 version of a library and a 1.2.1 with a symlink? As long as the interface is the same, then it does not matter. If there is a bug in the new code, then it needs to be fixed. Period. Versioning won't resolve this problem, no matter how much you want to push it. > if the eclass interface is intact but the underlying code does break > things , the user doesnt know games_make_wrapper still works or not, he > only knows it is still there The underlying code shouldn't break anything as it was tested before committing it to CVS. I am really starting to question whether or not you comprehend the concept of actually testing something before committing it or not. > if all the fuzz is about games devs and their one finger salutes and > people advice me to size my proposal down to system only packages, whch > are much moer critical than some game you wouldnt find in a production > environment, then im more than happy to do so I can tell you for a fact that I will not waste my time doing version bumps to eutils.eclass every time I make a change to a function that I use, such as make_desktop_entry. If you want to try bumping versions of this eclass, I'm sure you will meet with quite a bit of opposition simply due to tree size. This has nothing to do with games or not. I am simply using them as examples of where your proposal has holes in it big enough to fly a C-5 Galaxy through. This could apply to any eclass, whether it be games.eclass or linux-mod.eclass, the point is the same. > same for vim*.eclass So rather than combat the arguments that show how your proposal fixes nothing, you want to make exceptions for the cases where it doesn't fit your rosy perception of how things should be? > the core thought is to protect the system Great. Don't commit something that breaks the tree and you won't have to protect anything. > i didnt want to cut corners and left it globally in the proposal > focusing on system only is something im more than willing to compromise > on, since at this point the resistance seems to come only from non > system critical things If you want, I can start looking through kernel and toolchain eclasses to point out the same examples where your proposal simply won't work or will cause more problems than it fixes. Both ciaranm and I are using eclasses that we are more familiar with as it makes for quicker arguments. You seem to be taking this and once again twisting the facts to match your view of the world. > i cant talk for patrick there > > certainly there were things a production environment would like to have > predicatbility for, be it httpd, db, or other usable packages, kernel > even since there seems to be interest there too to have versions even if > less fine grained than i keep on using it for examples sake, games > packages are certainly not one of them, nor is the editor used there > that critical that the idea should die on one editor having a heavenly > perfect eclass Perhaps you should move your arguments over to the glep19 guys, where you might be accepted a bit better. You seem to be focusing on solving a problem that does not exist, yet you persist when several examples have already been brought out to show why your proposal is not a good idea. > forget for one moment the idea your eclasses would be affected, and > objectively look at what is proposed would create a saner more > predicatble system, i think yes, and companies interested in gentoo for > their systems would probably also be interested in seeing server > packages undergo the same predictability enhancement /join #gentoo-server > i doubt they would turn a nose on gentoo if they get a saner system for > their production environment that does not allow them to have the same > predictability on games or one editor Once again, poking a stab at our examples because you can't refute them. Good argument. Keep it up. > i would think they would appreciate the small effort on our part to keep > their systems sane, and your avg use Joe Happy would enjoy the same > predictable system Somehow, I always thought that our users wanted features and capabilities. If I have to waste my time doing hundreds of commits every time that I change an eclass, they won't get what they want. Allow me to use another eclass, eutils.eclass as another example. I use make_desktop_entry to create .desktop files for window managers. This is something that corporate customers would expect, wouldn't you say? Now, by your account, if I changed this function, I would have to create a new version of eutils.eclass for this modification, and if I *wanted* to retroactively apply it to all ebuilds that used this function, I would have to spend hours scouring the tree for every ebuild that inherits the older version and update them all. What if my eclass change is a bug fix? Your entire argument is based on the assumption that all changes to eclasses are done to break compatibility, when the truth is that very few of them are, and in most cases, a new eclass is created when this happens. I'm sorry, but your proposal sounds like a good way to waste developer time and to stifle progress in the name of predictability. There is a project for this. The glep19 guys are already exploring this with a complete separate tree. Don't go pushing this crap on the normal tree in the guise of catering to the enterprise. -- Chris Gianelloni Release Engineering - Operations/QA Manager Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
