App duplication again (Re: new project in kdemultimedia)

Andreas Pour pour at mieterra.com
Sat May 4 20:06:37 BST 2002


Neil Stevens wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Saturday May 04, 2002 07:17, Hetz Ben Hamo wrote:
> > > > OK, meanwhile I was told that this new CD burner (k3b) in
> > > > kdemultimedia adds another 700+ strings which means that we now have
> > > > something like 2000 strings for CD burning apps alone for each and
> > > > every of our 50+ translation teams. Even if we can re-use a lot of
> > > > these strings I think the situation is getting absurd. And I'm not
> > > > only talking CD burners here.
> > >
> > > If translators don't wish to translate the new app, nobody's forcing
> > > them to do so.
> > >
> > > Why should translators get a double super veto over what goes into
> > > KDE?
> >
> > And why not finally have a vote page for the following applications:
> 
> Because KDE isn't a democracy.  

To some extent it is, and has to be.  You need to go back to the basic
purpose of putting something into KDE's CVS.  And when you do that, bear
in mind that "sophisticated" people can get their apps from the
Internet, compile themselves, decide which they like most, etc.  The
"core" distribution should instead be targeted at the unsophisticated
user, the one that will be confused by multiple applications, that wants
to be able to use the machine at the office or at a friend's and have
the same tools as the machine at home.

To get a good grasp on it, compare the user API to a developer's API. 
Learning to use an application, for a user, is much like learning to use
a class, for a developer.  Do we have 4 classes in KDE to open a file,
combined with a situation that as a developer you do not know in advance
which class is installed on a a target machine?  No, that is an
impossible situation.  It leads to fragmentation, and if MS has proven
anything with its market domination, it is that having a single
"standard" desktop is *highly* desirable for people.

The job of the "release coordination" is to find the best apps for the
job and put them in as default.  The others should be optional and
should not be part of a "core" package.  This is not an easy job, for
sure, but I think we are capable of doing a good job at it.

> Developers are under no obligation to. That is, KDE has no leverage to force the
> developers if the result doesn't go the way they want.  KDE can only
> enforce a negative - removing apps and reverting commits.  It can't force
> developers to "team up," or force a developer to move into CVS and comply
> with KDE CVS rules.  It can't force developers to add features and
> redesign UIs.

No, but it can encourage it, by rewarding developers who do that. 
Having an app in KDE CVS is a privilege which carries responsibilities;
if you do not like these responsibilities, develop your app outside KDE
CVS.  One of the responsibilities is to reuse code and avoid duplication
of effort.

KDE is growing up, it's time to realize that and act accordingly.

> This is a good thing.  User feedback is important, but to have users make
> decisions is to ask them to take over some of the developer
> responsibility.  

The point of packaging is to create something useful for users (if
nobody used the app, there wouldn't be much point of putting it in KDE's
CVS).  Hence their opinions do matter.

> The average user is not necessarily inclined nor
> qualified to make release decisions in a way that is in line with KDE's
> goals and previous success.

The "average" user does not read the dot or vote on applications. 
People who read the dot are typically people who are involved in KDE and
care about it, so I think their views deserve consideration.
 
> Further, to put these up for a vote assumes that the options in each vote
> are interchangable.  They are not.  Hetz, you and I clashed at least twice
> on whether CD Bake Oven or KreateCD would be better for KDE.  We both
> argued that one was better for a particular group of users.  So, just as
> we have KWrite and Kate for different kinds of users, why not have CD Bake
> Oven and KreateCD for different kinds of users?

KWrite is a subset of Kate.  I don't have an issue with having a "quick"
frontend to *the* KDE CD-burning app which has limited options (using
mainly defaults) - it's still essentially the same app and same
codebase.

In the long run it is better to have one default application, and let
people download everything else separately.  Part of the responsibility
of having a distribution (even if in the case of KDE it is source code
only) is to make some of the difficult decisions for the user.  Letting
other users be involved in this process is smart.
 
> Lastly, any online vote would just hand the results to whoever has access
> to the most IP addresses to vote from.

No decision-making is perfect, yet we still have to make decisions. 
Generally the goal is to obtain the best information available, even if
it is not perfect. 

As it stands now, how should the decision be made, depending on who
sends the most emails on the topic to this list?  What makes *you*
better qualified to judge the CD-burning apps than the "average" user?

Ciao,

Dre




More information about the kde-core-devel mailing list