About Kamala

[Mauricio Piacentini]

Michael Pyne wrote:
> 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.

OK, got it. But I thought that the definition of extragear was "stuff 
that will be released in its own schedule", and playground was for 
"things under development and not ready yet". That was the initial 
assumption, and lead to the question: what we do if we want to release 
with KDE, and are past the playground stage, and do not have a suitable 
module?

> 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 understand. But by this criteria maybe we do not need all the games or 
kdeedu applications as well. I might *feel* that we do not need both 
KShisen and KMahjogg, for example. It becomes something highly difficult 
to define, it is good that we are having this conversation.

> 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.

> 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.

That was the discussion we had in the kdegames BoF at Akademy. We did 
not feel that the Gnome route has the best for us: they basically limit 
the number of games to something like 12 ou 13, and if one goes in, 
another one goes out. This implies the existence of someone that 
"decides" which games should be part of the module. In the long run I do 
  not think this shapes the best community, although it *might* shape a 
more coherent desktop offer.
That is why we thought about adding an indication to packagers inside 
the kdegames module. After all, the SVN structure does not have to be 
mirrored by distros. So we would categorize the games as part of a 
MINIMAL, BASIC, EXTENDED or COMPLETE subpackage, just to make the life 
of distros easier. Our intent with this is perhaps to attract big scale 
projects like Boson or other games so that they feel welcome inside our 
SVN structure. With this, we would have the best of both worlds: we 
would not limit the number and scope/size of games artificially, but we 
could still point distros to our pre-selected sets of applications that 
they could pick easily.
But we did not implement this, yet. Maybe it is time to do so? And maybe 
with a provision for a place that applications like Kamala or your 
Preventive Maintenance Schedule could live, knowing that they will be 
tagged and released aligned with the main KDE schedule?

Regards,
Mauricio Piacentini