Re: Is kde-cvs still alive?
Marc Jeffrey Driftmeyer <[email protected]>
| Newsgroups | gmane.linux.debian.kde.cvs |
|---|---|
| Organization | ReAnimality Inc. |
| Message-ID | <[email protected]> |
So tell me how is it that Darwin which is built from thousands of developers are still able to do SQA? It's called someone takes charge of the reigns and manages it. This is a dig at the KDE folks for dodging this question that has been asked quite often. The days of being an hobbyist alternative to Windows for x86 are over and I for one don't want to see RedHat dominate the Linux world, just because they officially offer Enterprise level support. KDE is the best option Linux has in debunking the crap the world has to swallow from Microsoft for x86 codebase. To compare KDE to OS X of course would be moot. If Qt was not targeted for the Enterprise than they wouldn't offer an Enterprise version. http://www.trolltech.com/products/qt/pricing.html And to debate a topic offline, in response to my online topic either shows that you are worried I'm a fanatic who would debate down a rat's hole for the sake of debating or you don't want to be constructively criticized. For the record. What I cannot stomach is people who tell people to be lucky to have these Debs when one obvious benefit and point of these Debs were to help Opendoorsoftware.com gain exposure, business-wise. It is a two-way street. As you stated I am quite thankful for the work on such that has already been done, and quite intrigued with the option to help. However, are we all here because we want to settle and be content for even having this? Or do we want it to improve, either by directly hacking the C++ or filing bug reports? I'll let that be a decision for each individual. I personally don't like C++ and since I don't see work on Objective-C or Java working much within KDE I'll stick to filing bug reports. Debian unstable/sid is more stable than most distros I have seen and the dselect/apt world is a wonderful structure. What still seems to be 'voodoo' is the magick keys to making the builds work which is why I referenced the moving target. Duh life is about Change and I'm not about to go into an esoteric conversation on such obvious observations. However, you'd think something as simple as build configuration options that are "guaranteed" to work would be possible so we wouldn't have to be spending hours in guess work, on our own. Yes I'm in the midst of building Qt and KDE CVS as well as LyX 1.3.3 and other projects. I'm not thrilled with i386 based Debs when most people do not run such older based optimizations. My views on how this industry has room to grow can be best summed up by Bill Joy in this fortune article: http://www.fortune.com/fortune/technology/articles/0,15114,490598-1,00.html Sincerely Yours, Marc J. Driftmeyer Kevin Poorman wrote: --- Marc Jeffrey Driftmeyer <[email protected]> wrote: Complain? Whine? As I recall, the builds were problematic with glibc and gcc and we were asked to either downgrade or wait for an update. No actually you were made aware of your options, which were a: Regress the package version. b: Stop tracking the CVS builds and use the default kde packages. c: deal with the crashing programs while you wait for the next package update. The choice you made to follow the CVS builds instead of the normal kde builds was yours alone. The choice you either made or get to make regarding what to do with current package problems is also yours alone. To complain, whine, bitch, whatever about the ramifications of your own decisions is imature and counter productive. Having dealt with debs and the pain-in-the-ass build process that Qt produces--It is not Enterprise Quality if you want my opinion. I don't remember anyone asking for *anyones* opinion but *I* for one am glad to hear yours. It gives me an chance to correct a huge mistake that I see all the time. You see, Qt's goal isn't for "Enterprise Quality" it's to have a complete and cross platform toolkit; something that QT does well. Denouncing QT also does nothing productive for the KDE-CVS team. As unwilling as I am to believe you sent your e-mail to waste time, and degrade the hard work and hours of time that people have put into these .debs I have to admit I'm having a hard time seeing how your e-mail was productive. My idea of Enterprise quality is Openstep APIs and having worked with those for years both in support at NeXT and in the consulting world, Qt is still not there. Then your choices are, in order of *my* personal choice are: 1: Submit API patches to QT to fix the problems you *percieve* with the toolkit. Perhaps your changes will be accepted and then all the world can benefit from them. 2: Go back to using the Openstep API's. Perhaps you can still find work doing tech support for NeXT or perhaps even programming with Openstep. Either way if you feel that strongly about the nature of Qt, remember that no one is forcing you to use it and that you are free to *not* use it as you see fit. Complaining about something while refusing to change what you use, or the product itself is a waste of everyones time. KDE doesn't even have a consistent and standards tested approach to quality assurance that would guarantee successful builds and installations, for any individual to use. At best they give a best guess at what has worked in the past. Now that is braindead. Perhaps your unaware of this, but KDE is developed by hundreds perhaps even thousands of programmers in at least a couple dozen countries. As such there is no one to impose a "standards tested approach to quality assurance" and there is no time (due to the fact that the code base is, at any given moment in time, under construction somewhere in the world) to work at guarantee successful builds. Debian only adds a layer of complexity to do a solid but still in flux solution to package management. Debians package creation tools are in flux not the *package format* The build tools to *automate* the boring parts of creating a .deb file are always being tweaked. But the package management system itself is *not* in flux. Furthermore if the package creation tools bother you, don't use them. compile CVS by yourself. Then you don't *need* .debs James is doing one hell of a job offering these packages and as he said changes to Qt have only added to the headaches, combined with changes to Debian's sid distro. Yes, he is doing one hell of a job. So stop complaining! Sid is, by definition under constant construction... Chasing a moving target sucks. What a defeatist and pessimistic outlook. Life is a moving target. James also mentioned he is working on a document to build these debs. However, if even he is having trouble building these packages what are the odds that he'll have a chance to document it before Debian changes something again and thus make his document obsolete? As I've said before, I'll reiterate it here; Debian's changes are reflected in dependencies and compiler options not in the methodology to create a .deb Therefore your question is moot. Debians changes may affect dependencies or even may impact the ability of the kde-cvs source files from building but they will not affect the steps documented to create a .deb -Pkj __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com _______________________________________________ debian-kde-cvs mailing list [email protected] http://opendoorsoftware.com/mailman/listinfo/debian-kde-cvs