Re: Qt MathML Widget

Re: Qt MathML Widget

On Thursday 02 April 2009, Aleix Pol wrote:
> Should I wait for someone else to need it or move it already?

To a work branch or to kdesupport? Given the reasoning below,
and given that 4.3 feature freeze is around the corner, I think you should start
in a work branch, to polish it before it can go into kdelibs, and you don't
really need kdesupport since it wouldn't be released in that form, or do
I miss something?

> On Mon, Mar 23, 2009 at 5:34 PM, David Faure <faure@...> wrote:
> 
> > On Monday 23 March 2009, David Faure wrote:
> > The alternative, of course, is to do all this in a work branch and commit
> > the result directly to kdereview for kdelibs. Depends if you expect to be done before
> > 4.3 or not, in fact: if yes then it doesn't make much difference and working in trunk
> > saves from regular merges; if no then working in a work branch prevents temporary
> > classes (and even a temporary lib) being released at 4.3 time.

--

-- 
David Faure, faure@..., sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

Re: Qt MathML Widget

On Monday 06 April 2009, Aleix Pol wrote:
> To be fair, I'm not sure. I think it is nonsense to have it in abranch
> because it already is up and running for trunk's KAlgebra, and I need it
> there. We said it might be good to have it in kdesupport so that if somebody
> else wanted to use it, he could without copying code. That's all.
> 
> I'm not aware of any other users yet, btw.

OK... then it sounds to me like the code should stay in kalgebra until someone else
needs it ;)
Committing to retaining BC before it's actually needed, seems like unnecessary trouble.

--

-- 
David Faure, faure@..., sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

Final release schedule 4.3.0 + soft freeze

Hi,

After months of feature development, it is time to prepare for the 4.3.0 release. The release team has put up
the release schedule on: http://techbase.kde.org/Schedules/KDE4/4.3_Release_Schedule so we can
release at July 28th, exactly 1 year after 4.1 and 6 months after 4.2.

The schedule has been setup so that the first release candidate is released just before akademy, which is
the time that branching happens. So, at akademy everyone can either hack on new features or test and fix
last minute bugs in preparation of the release.

The first deadline is next Thursday. By then the soft freeze hits. Trunk is from that day on frozen for
feature commits that are not listed in the  planned feature document at
http://techbase.kde.org/Schedules/KDE4/4.3_Feature_Plan . Only bugfixes and the code
implementing the listed features are to be committed. The feature list also closes that day. Features not
already finished or listed on the planned features page will have to wait until KDE 4.4. 

Best,

Toma
Release Team

4.2.3 + 4.2.4 added to release schedule

Hi,

I've added two bugfix releases to the 4.2.x release schedule. Let me know if the dates are problematic for someone.
http://techbase.kde.org/Schedules/KDE4/4.2_Release_Schedule

I think 4.2.4 should be the last release in the 4.2.x serie, unless there is a pressing need for a 4.2.5, which
would then happen at the beginning of July.

Best,

Toma

About Kamala

Stanislas Marquis wrote:
> Hello Mauricio,
> 
> I am happy to tell you that Kamala actually does draw astrological
> charts (despite some Qt bugs).
> It can do very basic things like save/edit/delete chart, and get the
> current chart.
> 
> I am also writing because I think now the problem of where in svn repo
> the project should be, must be asked sooner or later...
> 
> I have looked around in repo and I think maybe utils or extragear
> would be ok but I dont really know the difference. But Kamala is not a
> game.... so.. what can I do now? who will decide? is there a mailing
> list I should write to, etc?
> 
> Thanks for help, Happy easter

Hi. Stanislas Marquis, cc'ed on this message, is working on an 
astrological application for KDE, named Kamala. He contacted me some 
months ago for help, as I expressed interest on writing an astrology 
program for KDE on my "People behing KDE" profile.
As it turns out, he has been working on it a lot, and it currently 
resides on playground/games. We did not want to start the whole 
discussion of "where to put an astrology program in the KDE tree" before 
we actually knew the coding effort was going ahead. And Eugene (from the 
kdegames art team) is also interested in helping with art and logo, so 
hosting it in the games playground was natural at the start. It was not 
enabled in the top level CMakeList as well.

But as mentioned by Stanislas above, the application is now starting to 
become functional, and we need to find a place for it. I think utils is 
not the case, and extragear for what I know is for apps that want to 
release independently of KDE, isn't it? Even if it is extragears, we 
need a subdirectory there, and none of the existing ones seems suitable.

So... what now? kdetoys and kdeutils do not seem right. Kdeedu is 
probably not good as well, as it is more geared towards sciences that 
are part of the curriculum in most countries. Do we start a new module? 
If we decide to do this, then maybe it could be a place for other 
applications (currently on kde-apps) to live as well.

Regards,
Mauricio Piacentini

Re: About Kamala

On Sunday 12 April 2009 18:50:37 Mauricio Piacentini wrote:
> Hi. Stanislas Marquis, cc'ed on this message, is working on an
> astrological application for KDE, named Kamala.

> But as mentioned by Stanislas above, the application is now starting to
> become functional, and we need to find a place for it.

> So... what now? kdetoys and kdeutils do not seem right.

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.

However that's all kind of moot as I think extragear would be the best place 
for it, as long as Stanislas doesn't mind having to do the release process.  I 
agree that no existing extragear category seems to apply.  I've heard 
extragear/extra recommended, which I would agree with.

Hope this helps.

Regards,
 - Michael Pyne

Re: About Kamala

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?

> However that's all kind of moot as I think extragear would be the best place 
> for it, as long as Stanislas doesn't mind having to do the release process.  I 
> agree that no existing extragear category seems to apply.  I've heard 
> extragear/extra recommended, which I would agree with.

What we were trying to find is a place that we could put the application 
to be released in the regular KDE schedule, if possible.

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

Would you still suggest kdetoys as the umbrella module for these? I 
would say that something like kdemisc or kdespecialinterest could also 
apply.

What I am thinking is that maybe there are more than a few good 
applications out there that could benefit from living on our tree, but 
the authors can not find a good home for them in our current structure. 
In kdegames we took the decision of not excluding games from the tree 
based on the number of games or any other excluding criteria, like size 
in MB of the compiled package. If we one day end up with 500 maintained 
games, they could all be in KDE/kdegames. 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.

Regards,
Mauricio Piacentini

Re: About Kamala

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

Re: About Kamala

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