About Kamala

[Albert Astals Cid]

A Monday, 13 of April de 2009, Mauricio Piacentini va escriure:
> 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?

playground still has this meaning but afair we changed extragear to 
"stuff that will be released in its own schedule OR does not fit in what we 
think are essential programs of a desktop"

For the second range of programs there is the config.ini file in 
playground/utils/createtarball that lets you add your program for release 
inside the "extragear release" that happens at the same time of KDE releases.

Albert

>
> > 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
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team