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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.