About Kamala

[Michael Pyne]

On Sunday 12 April 2009 21:52:41 Mauricio Piacentini wrote:
> Michael Pyne wrote:
> > Well if we were to call this a KDE application at all then what's wrong
> > with kdetoys (without trying to sound like flamebait here but I don't
> > think it meets the definition of kdeedu).  I would hardly start a new
> > KDE/ module for it as well.
>
> Well, why would you not consider it a "KDE application at all"? It uses
> kdelibs, is written in C++, is developed inside our SVN, has members of
> the community as contributors... can you elaborate?

I mean as something distributed by kde.org as "the KDE desktop environment".  
Obviously we can't just dump all kdelibs-using software into /trunk/KDE (even 
done in C++ by our best contributors), which is one of the reasons that we 
have extragear and playground.

For instance if I were to make a Preventative Maintenance Scheduling program 
it would probably not be suitable to go into kdeutils or kdetoys because I 
don't see it as something that KDE "the Project" needs to solve.

> I do not want to start the astrology-is-not-a-science discussion here,
> as I do not think this is what matters. Any discussion that considers
> this belief (scientific or not) as the basis for including or not the
> application in KDE will turn into a flame fest: some people will point
> the historical importance of it, others might point to universities in
> the US that even today teach it (like the Kepler College), etc.

Well there's a fairly decent definition of things which are science and things 
which are not, mostly involving testing theories by experiment.

That doesn't change your point of its importance though, but I just see this 
in the same fashion that I see Greek mythology for instance.  It's a subject 
that certainly has a lot of university-level discussion and thought behind it, 
even though it has been discarded as a scientific framework.

> The
> question is not that, but instead finding a place for the
> "non-traditional" applications that want to be considered for release
> with KDE. So, let us consider other theoretical applications, some
> difficult to handle:
>
> - A Genealogy program
> - An application to write dance notation (coreography)
> - A Biblic analysis/cross-reference tool

That's actually a good lead-in, and I'm glad you asked the question.  I don't 
personally feel that any "non-traditional" apps should be distributed by KDE 
under the K Desktop Environment banner that things in /trunk/KDE exist in (but 
that's just me).  Now maybe I'm wrong and we're actually trailing standard 
practice here (e.g. does Mac OS X or GNOME include astrology programs in their 
localized versions for areas where astrology is important?).

So in my mind the technical question is whether, wherever Kamala ends up going 
in SVN, there is a way to get release-team to handle packaging it as well, 
since right now the only framework for that is basically /trunk/KDE.

> Packagers would of course be
> free to do what some do today: ship only the best 4, or 5, or 10 on
> their distros. By the same reasoning, having something in kdetoys or
> kdemisc or kdespecialinterest does not mean it has to be shipped by
> every KDE distro: it just means it is released in-sync with KDE, as is
> part of our community.

Well right now when packagers do that it is at much extra effort to break up 
our releases.  What KDE actually ships is source code for modules, unbroken.  
If we were to agree to some standard means of grabbing individual applications 
or libraries then we'd be maybe be able to say that application foo is made 
available for interested parties but is not part of a standard KDE desktop 
module.  But right now I don't think that's where we're at.

Regards,
 - Michael Pyne
>
> Regards,
> Mauricio Piacentini

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20090412/ef9e0ecb/attachment.sig