NOV
28
2002

KDE-CVS-Digest for November 29, 2002

I have started doing a weekly review of the kde-cvs updates. Check out the latest issue and please comment. Any ideas that would make the information more useful is welcome. My purpose is to give links into the code, and some pertinent discussion. This hopefully will add to the body of discussion and information available to users and developers of kde. Please be easy on the server...

Comments

Thank you for your efforts! An overview of the very heavy traffic kde-cvs list could be nothing but useful to the KDE community in general. We will be glad to host you on the Cyberbrain.net server. Then hopefully these 4 issues (and the last 3 KC KDEs) can be posted on LinuxToday.

PS Woo, it looks like Richard Dale is back...


By Navindra Umanee at Thu, 2002/11/28 - 6:00am

"PS Woo, it looks like Richard Dale is back..."

Thanks Navindra. Sorry I 'disappeared' - haven't had any time at all recently. I'm looking forward to doing kde stuff again..

I sent an announcement to the kde-devel and kde-java lists about the java and c bindings regenerated for Qt 3.1/KDE 3.1.

-- Richard


By Richard Dale at Thu, 2002/11/28 - 6:00am

What about the Ruby bindings? Could you make them work, please?


By Me at Thu, 2002/11/28 - 6:00am

Me too!
Ruby rocks..


By dah at Fri, 2002/11/29 - 6:00am

say what? why dont me and you, heh heh "wink"


By derek at Thu, 2004/01/15 - 6:00am

I added an -fruby option to the kalyptus bindings generator to generate the same output as SWIG would have, without needing to manually prepare loads of SWIG interfaces files. I didn't get round to finishing that though.

Since then Ashley Winters has come up with the idea of smoke, where a single libsmoke.so lib can be used for any scripting language such as perl and ruby. You just need a language specific interface for ruby to that.

And I think the Kompany might also be doing something about getting up to date ruby bindings too.

So something will probably happen with up to date ruby bindings sooner or later..

-- Richard


By Richard Dale at Fri, 2002/11/29 - 6:00am

I would also add that the Portable.NET project is contemplating a Ruby --> CIL compiler. If this happens (they need some more volunteers who are interested in writing a Ruby compiler ;) you will also see Ruby bindings via the existing Qt# binding as these are really CIL bindings not just C# bindings.

Cheers,

Adam


By Adam Treat at Fri, 2002/11/29 - 6:00am

Why not do this as part of KDE Traffic ?

The thing I would like to see is cvs statistics per week:
- 5 best comitters
- nb of commits per projects


By Philippe Fremy at Thu, 2002/11/28 - 6:00am

http://kde-stats.berlios.de has some old stats, not up to date anymore.

If someone could come up with an easy way to do this, please show me.

Derek


By Derek Kite at Thu, 2002/11/28 - 6:00am

For one thing, it's taken.

Second, the focus is different. The KC-KDE is by the developers, and seems to focus on what they are going to do. Which is important information. For example, I link to the kmail future developments in an older kc.

What I am focussing on is the code that gets added to the repository. The code is done, and I think the strength of free software is the code and making it easy to review. Part of my purpose is to get to know the huge body of code that is kde.

Derek


By Derek Kite at Thu, 2002/11/28 - 6:00am

Hi Derek,

Your work is very nice and useful. Could you suscribe to the kc-kde@mail.kde.org mailing list.
The people involved in KC KDE are discussing about which format we should give to KDE Cousin and I think we should have some coordination with you.

I would like also to hear from Dot readers. What would you prefer ?
a) Pure summaries of discussion on mailing list with nothing added
b) Information on development (from the mailing lists or outside the mailing lists) like the summary on translation in the last KC.

a) is exactly what Zack Brown is doing for the Kernel mailing list.

b) would be more similar to the Gnome Development News.

a) is also a lot of work and if we don't have more contributors, we won't be able to do it on a weekly basis.

Cheers,
Charles


By Charles de Miramon at Thu, 2002/11/28 - 6:00am

Personnally I'd prefer a little of both:

I think what Derek has done is great, but having the relevent parts of the emails quoted as in Kernel Traffic is much more convenient. I think recent kernel traffic issues have perhaps strayed a little too far to being merely direct quotes from the kernel ML, earlier issues tended to summarise the emails a little more so there was less direct quoting.

Having some general information on the development of KDE as well purely tracking the lists is also very useful. I think people are interested in the summaries, but that on their own they lack some of the authority given by quoting the relevent mails.

Cheers

Rich.


By Richard Moore at Thu, 2002/11/28 - 6:00am

To make myself clearer. I would like to make for the next KC a summary on what is happening with the bindings for Perl and C#.

There are some interesting threads on the mailing lists but there are lot of points that I don't understand (I'm not a programmer). So, I thought sending private e-mails to the developpers to ask them questions and then round up their answers and the relevant e-mails on the mailing lists.

The pure KC solution, would be to use only the mailing lists and give more excerpts so people with more knowledge can figure it out even if I can't.

Each solution has its pros and cons.


By Charles de Miramon at Fri, 2002/11/29 - 6:00am

I'd be happy to answer any questions you have regarding those threads on qtcsharp and kde-perl :-)

Cheers,

Adam


By Adam Treat at Fri, 2002/11/29 - 6:00am

Yeah, and I'll answer any questions about the silly proposals I've been spouting in public where anyone can see them. Shame on me for not documenting!


By Ashley Winters at Fri, 2002/11/29 - 6:00am

Yes contact the devs, the MLs are not always the pure result.

As for KOffice, some stuff is discussed on IRC and the final may not be completely clear on the ML (even if I try to post later on there as well).

So if something is unclear, just try to contact the devs. I'm happy to help here.

I prefer the quotings withs some personal comments, even if some of the comments I don't like ;-) For me it's clear, this is the impression of the writer and everybody can have his own view, especially the ones who make the work for others and write articles.

Philipp


By Philipp at Fri, 2002/11/29 - 6:00am

My mantra is: the one that does the work decides.

Do what you can do and what you want to do. If you want to do an overview of what is going on on a list without citing the threads, then ok. Sometimes, it makes the whole thing easier than reading post after post to get the global idea.

KC-KDE is low on resources. Whatever you do is good because the alternative is nothing. And do it the way you like it, Free Software is about fun.


By Philippe Fremy at Fri, 2002/11/29 - 6:00am

GNOME Development News is pretty much empty content-wise. Much back patting and applications but not much else.


By ac at Thu, 2002/11/28 - 6:00am

Sure, and you head also seems to be empty, brain-wise..

Can you please stop the useless trolling on both the Gnome and KDE sites?
Thank you.


By Richard Moore at Sat, 2002/11/30 - 6:00am

Do you really want to hurt me
Do you really want to make me cry
Do you really want to hurt me
Do you really want to make me cry


By Christian F.K. ... at Sat, 2002/11/30 - 6:00am

Ack! I never knew this discussion existed. KDE is HUGE. Does anybody know it all?

I see that what I have tried to do came up in the discussion. Follow the cvs, comment on what is coming in.

My goals are quite simple. Glean as much useful and interesting information out of the cvs commits, comment on a few, in maybe 2 or 3 hours a week. A few threads on the devel lists are pertinent to the development process, comment on them.

The challenge is to keep it simple enough to be repeatable. There is so much stuff, and lengthy commentary could be made on literally hundreds of commits.

One thing I probably will change is instead of simply a bug reference number, use a bit of descriptive comment.

Richard Moore's comment about quoting some of the list is useful. Maybe it's my preference. but I like reading threads. The most interesting part of software development is the wetware.

Derek


By Derek Kite at Thu, 2002/11/28 - 6:00am

Honestly, I like both a) and b).

I am not on big KDE mailing lists with heavy traffic (kde-core, kde-devel, koffice, ...) but I like to know what is currentely being discussed and developed in KDE. What I do is that I wander through the mailing list archives.

For my, anything that help to know what is going on inside KDE is good.

So if you have time to make lengthy summary with lot of detailed references, then do it. But if you just have time for a short summary, this is still very interesting for people like me. Even a very brief monthly report noting the interesting threads on the mailing list is informative.


By Philippe Fremy at Fri, 2002/11/29 - 6:00am

I am sure you could share the infrastructure with KC-KDE. And your job can be seen as the KC-KDE of the list kde-cvs.

> The KC-KDE is by the developers, and seems to focus on what they are going to do.

Yes, because this is usually what is discussed on a mailing-list. It doesn't mean you can't say more.

KC-KDE needs more contributors. If the current way KC-KDE works doesn't reflect what you want for your summary, I am sure you can discuss with them to find a better arrangement.

With the lack of resources of KC-KDE, I would find it a pity that there are separated forces doing summary of KDE development.


By Philippe Fremy at Fri, 2002/11/29 - 6:00am

> The thing I would like to see is cvs statistics per week:
> - 5 best comitters
> - nb of commits per projects

5 "best" commiters - how are you going to determine who's "best"? By the number of commits? Everybody receiving kde-cvs@ mails would be definitely happy to see traffic increase on this list because of some people trying to improve their stats by doing several small commits instead of one large. I don't mean anybody in particular, but there of course would be people tempted to do this. This is similar to the bugs.kde.org weekly statistics, but the consequences are different. The only way how to get better rank at bugs.kde.org is to close more bugs, even if simple ones - i.e. there's a good result of the stats, more bugs closed. For kde-cvs@, the only result would be kde-cvs@ traffic increase - not good at all.

I find listing commits the way it's done in this review to be a much better way (but it of course requires a person like Derek who's brave enough to watch all the commits :), instead of simply counting them).


By L.Lunak at Fri, 2002/11/29 - 6:00am

"best" is an inappropiate term. The five people that committed the most.

For your other argument, do you really think that KDE developers are ready to cheat in CVS commits or bug closing just for the pleasure or appearing in the top of the stats ? I don't think so. Usually, developers have more interesting stuff to care about.

The best way to close more bugs is to add many fake one at once, then close them all. Have you seen this happening ? I think you are underestimating the commitment of KDE developers. We are not here to have our names in internet but to help the project move forward.

Of course commenting the commits is good. But I like to have statistics, it is always interesting.


By Philippe Fremy at Fri, 2002/11/29 - 6:00am

> "best" is an inappropiate term. The five people that committed the most.
That's quite easy. First one is the bot updating i18n stuff. Places 2-5 are for the 4 most active i18n teams. You could of course count only some kinds of people working on KDE, but which ones would that be, and would it be fair to the others? How was it ... ah yes, 'Lies, damned lies, statistics'.

> ...KDE developers are ready to cheat...
I wasn't talking about cheating. If I write some code which involves changing four source files, I usually commit them together, so that it's easier to track back the whole change later using the kde-cvs@ mail saved at lists.kde.org . But with statistics, I would be tempted to commit them separately, which would increase my number of commits. That's not cheating, is it? Even humble people like from time to time to be first. But besides lifting the developer up in the statistics, this would result only in bad things - kde-cvs@ more flooded, the change scattered over more kde-cvs@ mails. Nothing good from it, besides knowing that Joe Developer commited the most changes this week, because he changed one header file in kdelibs and had to change bazillion dependent files in whole CVS. How is this interesting?

The same way, I wasn't talking about cheating with bugs.kde.org . I meant people who simply go over the database and close/fix invalid/alreadyfixed/simple bugs. However, this has a good thing - the number of open bugs is reduced, and other developers don't have to mess with old bugreports and so on (and I'm grateful there are people who do such cleanups). That's the difference why I find bugs.kde.org statistics (at least somewhat) good and cvs statistics bad. Bugs.kde.org statistics may make some people do a better job, cvs ones can't. Some people may spend more time doing the boring bugs.kde.org stuff, but people won't code more than they already do just to get better rank in statistics.


By L.Lunak at Fri, 2002/11/29 - 6:00am

'5 "best" commiters - how are you going to determine who's "best"?'

I got a quick hackup using J. Mallett's cvstat at http://members.shaw.ca/dkite/log.html

Not a useful log of anything except to see what stats would tell us. I hacked the perl script to give me the top 5.

The high number for some developers is merging the kroupware and make_it_cool branches of kmail.

Is the information useful? I don't know. I think over time you would see certain developers again and again.

Anyways, it's quite easy to produce. I use the cvs log for other stuff also. If there are too many complaints, I'll drop it.

derek


By Derek Kite at Sat, 2002/11/30 - 6:00am

I've been wondering what's holding up KDE 3.1 when the release schedule says that RC4 should be out by now, or released. As that posting in your report suggests, new tarballs will be up following the fixes of the 25th's tarballs; will this be the final 3.1?


By Paul Kucher at Thu, 2002/11/28 - 6:00am

Yes I am with Paul (Kucher) on this one, what IS happening with the KDE 3.1 release. Adecision was supposed to have been made 4 days ago yet I have not seen a word about any problems or updated release schedule.

Hell of course I am sympathetic that most of the developers are doing this in their time and we must remember and respect that. But...they have always been punctual in the past, if not with releases then always with information on the release.

Finally is it just me or is KDE quality slipping a little, I am concerned as long time user of kde that they (the developers) are perhaps pushing themselves too hard. Sure we all adore the eye candy, and fantastic features they bring us, but not if good old apps start to get buggy.

Just a few thoughts from a still loyal and very very grateful user of KDE.

Cheers

"Racism ? = How so, there is just one race, The Human Race." anon


By Paul Sauter at Thu, 2002/11/28 - 6:00am

Sorry you can't have it both ways. Late software = better quality. The delays are due to bugfixes. kdebindings required lots of late work.

As I say to my daughter all the time, "Patience is a virtue" (ducking)

Browse through the cvs list and you will see huge numbers of real quality enhancing work. There are lots of discussions on how things look, but the vast majority of the code updates are dealing with how things work.

Derek


By Derek Kite at Thu, 2002/11/28 - 6:00am

Derek,

I agree with you: Late soft != better quality.

But...

What about the project coordination? Give us a new release date.

We are totally crazy to see the new features working asp.

Thanks to all KDE developers.


By Paulo Junqueira at Wed, 2002/12/04 - 6:00am

RC4 went to packagers, with the expectation of a release a week later. It got delayed because of more last-minute bugfixes, and an updated release candidate (RC5) went to packagers a few days ago. My guess is hopefully early next week will be 3.1 final.

Barring insanely important changes, the tarballs available to packagers will be moved to the stable tree very shortly.


By Benjamin Reed at Fri, 2002/11/29 - 6:00am

> Adecision was supposed to have been made 4 days ago yet I have
> not seen a word about any problems or updated release schedule.

Well, updating the release schedule is a little pointless now that the release has finished. However, there's news on kde-core-devel:

http://lists.kde.org/?l=kde-core-devel&m=103824444618699&w=2


By Chris Howells at Fri, 2002/11/29 - 6:00am

OK Thanks Derek, Benjamin and Chris.

Now that you have pointed out what the reason is I am once again satisfied. I really didn't mean to come across as impatient or annoyed by this. However I have been a little miffed because for the first time with KDE I have been suffering critical data losses through kmail. But comparing that to multitude of times when I have been so grateful for having had a reasonably upto date backup under windows (tm - registered trashmark :-)) I guess I should have been a little more patient.

Anyhow with the release of 3.1 now imminent I look forward to utilising the efforts of this outstanding community of developers (and also others).

For the record as someone who runs a multi-national non-profit I really would be lost without the KDE communitys' efforts as I would not be able to afford the extortinate prices expected for such feature laden quality software. The impact of having to pay for such software would doubtlessly affect our projects massively and thereby the professionals and patients we serve.

So a big THANK YOU

from ICORP


By Paul Sauter at Fri, 2002/11/29 - 6:00am

cool they mentioned one of my bugs :) ... if only they would do something about

http://bugs.kde.org/show_bug.cgi?id=51061


By cbcbcb at Thu, 2002/11/28 - 6:00am

Actually there were some patches that were committed to fix memory leaks in konq. No links, sorry.

Derek


By Derek Kite at Thu, 2002/11/28 - 6:00am

Glad to see another Canadian into KDE ;-)


By John Hughes at Thu, 2002/11/28 - 6:00am

Me too! Me too! (There are lots of us from up here in Canukistan ;)


By Sheldon at Fri, 2002/11/29 - 6:00am

*chuckle* canukistan ..

it would be cool to get a bunch of KDE'ers together out here in the West sometime. i've yet to actually meet another KDE hacker in person. sad but true. =/

i'm madly jealous of zack and ian's pending xmas adventure in phili.


By Aaron J. Seigo at Fri, 2002/11/29 - 6:00am

hi guys, with a little luck I'll be in vancouver in time for christmas for a nice long stretch, so I'd be glad to catch up with other KDE folks. You have no idea how lonely it was without other KDE developers in Oz. ;)

(Well not counting Martin Jones but brisbane and melb are far enough for it to feel like a different country)


By taj at Sat, 2002/11/30 - 6:00am

The content is fine (even 2 bugfixes of me have been mentioned ;-).

So some improvements I have in mind:
General:
- The style is a bit compressed. Please use more breaks, indentation and spaces to seperate the content a bit.
- I like the usage of different font colors as in the cousins. How about using it here as well?

Bugfixes part:
- Use a "tab" to align the bugnumbers
- Seperate by module like:
kdelibs:
+ khtml: 50956, 35408,...
+ kdecore: 51026
...
kdebase:
...
- If you post the text as well, just make the bugnumer as a link, the text doesn't need to be (just optical)

New code additions part:
- Put in a header, what is affected (module or appname).
- I think links to koffice or kopete HP are not necessary. The readers of cvs/interested persons of what's going on on cvs and the link disturbs a bit the optical impression (or it gives me the impression there is something new to look at).
- The whole part is bold here (Mozilla), I asume you forgot to close the bold tag after the header.

Thanks anyway for your work,

Philipp


By Philipp at Fri, 2002/11/29 - 6:00am

> I like the usage of different font colors as in the cousins
I'll be using the cousins templates, and be included in the cousins. Hopefully the formatting will be better.

> Use a "tab" to align the bugnumbers
Good idea
A few comment so far seem to indicate the desire for more information on the page, less links. So for the bugfixes, I plan (here we go, show me the code) to do a ...

Product
Component - bugnumber - comment
bugnumber - comment
...
grouping the product and components. A script should be able to produce this reasonably easily.

>I think links to koffice or kopete HP are not necessary
Actually, I put the links for the most part when I read about a commit to say, k3b or kexi or kopete, and I didn't know what in blazes the application was. Then I got carried away...

>The whole part is bold here (Mozilla)
Really. Konq works. (checking in mozilla). Yes, the last part. And indeed I didn't close the bold. How come Konqueror does differently? A bug?

Derek


By Derek Kite at Sat, 2002/11/30 - 6:00am

Is it just me or is KDE CVS getting buggier to the end ?

I usually re-compile KDE CVS once per week using latest sources and I found out that the general stability of it is going heavily down. With todays re-compile I got a shitload of crashes and segfaults in various places that were stable with the last compile. I know dealing with CVS will heavily lead into this siutaitons but I also know that 3.1 will come out really short and therefore I assume that it should get more stable instead of instable.


By AC at Sat, 2002/11/30 - 6:00am

How shall I put this... that harmless looking bugfix from yesterday caused some regression.

On the bright side, it is fixed already. Just update kdelibs/kdeui.


By anonymous KDE d... at Sat, 2002/11/30 - 6:00am

but I also know that 3.1 will come out really short and therefore I assume that it should get more stable instead of instable.

3.1 has been branched, HEAD is now open. So expect it to get less stable, especially in the next months...


By AC at Sat, 2002/11/30 - 6:00am

Ahh that may be a reason then. I still thought that HEAD is 3.1 (This explains the huge changes).


By AC at Sat, 2002/11/30 - 6:00am

I wish the fixed bugs had more of a description on the various components, vs just the bug numbers. otherwise excellent.

+10 points for putting in my email about fixing italic fonts with XFT and adjusting fonts.conf ;)


By Dave B. at Sun, 2002/12/01 - 6:00am

Dave:

I will be changing the format of the bug list. I will have product / component then bug number and the short comment from bugs.kde.org. Should be better with more information. Seems a common request is to have more information on the page rather than having to link to it.

Derek


By Derek Kite at Tue, 2002/12/03 - 6:00am

:-(


By Anonymous..... at Wed, 2002/12/04 - 6:00am

Me too!! ;-) What's happening?


By starflight at Wed, 2002/12/04 - 6:00am

Pages