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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

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?

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.

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.

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.

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.

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)

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.

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

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.

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.