Table Of Contents
|1.||22 Jun 2003 - 4 Jul 2003||(20 posts)||Artsbuilder/Kdenonbeta|
|2.||24 Jun 2003 - 27 Jun 2003||(6 posts)||IDE?|
|3.||24 Jun 2003 - 27 Jun 2003||(10 posts)||Knopdex|
|4.||25 Jun 2003 - 3 Jul 2003||(39 posts)||introducing brockenboring|
Better late than never, I suppose. I'd tell you why it was late, but I suspect you wouldn't believe me if I told you. Let's just say I had a very good reason, and leave it at that.
This one covers two weeks. That's not the plan going forward. There wasn't a whole lot of interesting content, but a few very interesting ones made up for that.
Mailing List Stats For This Week
We looked at 1481 posts in 5755K.
There were 377 different contributors. 184 posted more than once. 107 posted last week too.
The top posters of the week were:
22 Jun 2003 - 4 Jul 2003 (20 posts) Archive Link: "artsbuilder->kdenonbeta"
People: George Staikos
Disclaimer - I did contribute to this thread, but as no one responded to my post and it was little more than a "me-too" anyway, I decided it's not a big deal if I report on it.
George Staikos said:
I'd like to recommend moving artsbuilder and other associated arts apps in kdemultimedia to kdenonbeta. It seems like they are unmaintained and at least artsbuilder is completely unusable. I spent some time on it, but it's full of STL and hand-coded pthreads and very hard to debug. Valgrind shows a very large number of UMRs and other problems. Aside from those problems, artsbuilder seems to have major usability problems too. Input fields don't work properly, amongst other problems.
As fallout, Arnold Krille offered to take over maintainership for artscontrol, And Stefan Westerfield popped out of the woodwork saying he'd been ill but should have more time to devote to arts now. Looks like it's been spared from kdenonbeta for the present time.
24 Jun 2003 - 27 Jun 2003 (6 posts) Archive Link: "kmail development(newbie)"
People: Patrick Lynch, Till Adam, Zack Rusin, Stephan Kulow
Patrick Lynch asked, " Do the kmail developers use an IDE to develop kmail? " Stephan Kulow said most developers use xemacs, to which Till Adam vociferously objected, saying:
I use vim. And so does Carsten, I believe. Don uses cat and Zack has a neuro-cranular interface, he deosn't need an editor.
Zack Rusin said that the neuro-cranular (cranial?) interface is in the next version of kde-emacs.
24 Jun 2003 - 27 Jun 2003 (10 posts) Archive Link: "KDE CVS Developers Edition of Knoppix (Knopdex)"
People: James Michael Greenhalgh, Scott Wheeler, Russell Miller
James Michael Greenhalgh had this to say:
I caught some discussion on kde-promo with respect to a KDE CVS edition of
Knoppix that I have been working on: "Knopdex". The focus on the disk is not
only the latest KDE from CVS HEAD, but the development tools to accompany it.
I've tried to include as many of the latest
developer/documentation/translation tools and docs that I could think of, but
as always I will be looking for feedback. Some of the possibilities of usage
- - - wannabe kde developer can get up and going very quickly
- - - translators can understand context of word usage without sacrificing their more stable builds
- - - documentation writers can do the same
- - - other non technical users can sneak a peek at development progress
- - - alternative future versions built with debugging for quick developer usage (ie download/burn iso, boot, check bug)
Anyway, I have a first edition to release, but I am genuinely concerned with some of the discussion I've seen, not only with this Knoppix project, but with my KDE CVS Debian repository. I've seen Scott Wheeler's sentiments on kde-promo@, on the dot and we've spoke about it on #kde-devel (I'm orth for those who don't recognize the name), and I know he is not alone in his feelings, as I caught the full discussion on development releases on kde-core-devel@ I think I can summarise the issue at hand (pardon the oversimplification): Making CVS easy for someone to be able to install/run allows for the average user who otherwise would not be able to run CVS HEAD, to do so. This results in half implemented features getting bug reports, feelings of low quality software and other developer/user aggravations.
Now with that said, in my defence, I'd like to think I do provide some valuable packages and time saving to users who are developers, would be developers, translators or those who want the latest bleeding edge and understand the price they may have to pay in terms of stability; much ike myself. I also monitor kde-cvs@, kde-devel@ and kde-core-devel@ and try to perform my builds at quiet times when stability is relatively good. Also, catching bugs while the code change is still fresh in the developers mind is a good thing. Skilled users are not the only ones who will catch bugs and heading problems off before they can grow even larger is good? I would like to think I do my best to provide releases only at times when things are fairly stable. I've also recently included relatively the same warning verbage on my website as Dan Armak who provides the Gentoo ebuilds of KDE CVS, which I find is a suitable caveat. Finally my continued packaging has allowed me to become more comfortable with the whole kde build system, bug triage, my own cvs commits, preparing Debian for the next release and general help to KDE developers and KDE itself.
All right, with all this said. what's my point? I have not released any information about Knopdex to the general public. I've mentioned it a couple times to peers and to a few Debian users on #kde-devel. I would like to have some level of support in my effort from the KDE team if I were to release the information. I have the capability of access restrictions on my web site or I can say "If you wan't it, send me an email and let me know and I can tell you where to download it from" or I can simply make this iso available to the public (maybe in kdenonbeta?) with suitable warnings or finally, not make it available at all? What are the KDE team's feelings on this?
Responses were generally agreed that this is cool, but there were concerns. Scott Wheeler responded thus:
Well, since I seem to be the leader of the opposition here, I'll throw in my ??? .02 . :-)
So, some of the mentioned strong points were:
< - wannabe kde developer can get up and going very quickly
Well, while I don't mean to trivialize building KDE, as it certainly is an learned skill, but someone that's hoping to get involved in KDE development should be able to aquire -- I mean, to be honest, building KDE is the easiest step of learning KDE development. ;-) (And note that just for starting to learn the basics of Qt / kdelibs, you certainly aren't required to use KDE from CVS.)
< - translators can understand context of word usage without sacrificing their
< more stable builds
< - documentation writers can do the same
Yes, I certainly agree that making something available for translators before a release that's easy to work with could be quite beneficial. But here's where I get to most of my point -- why at this point in the release cycle?
We're not even to the alpha phase yet and I don't think most translators really get going before we're nearing a release. To be clear, most of my objections to having a CVS live CD mostly mean "having a CVS live CD right in the middle of a release cycle when things are still pretty buggy".
At least before an alpha developers get a little bit of a heads up for what's going to show up on end-users' desktops. Of course there will be a good number of bugs in an alpha, but at least we have fair warning. ;-)
< - other non technical users can sneak a peek at development progress
I know that this is "cool", but the CVS version of KDE really is a special purpose thing -- it's a tool for the colaboration of developers (and here I include translators, doc writers, artists) to work towards making releases -- which are for end users.
The assumption of developers when dealing with people that are running CVS versions is that they *are* technical people overwhelmingly. I in general expect to be able to say to people reporting problems with CVS versions:
"Can you apply this patch and let me know if it fixed your bug?"
"Can you rebuild that with full debugging symbols and send me a backtrace?"
"Where is it crashing?" (i.e. app, kdelibs, Qt, ...)
And so on -- i.e. these are assumptions that I don't make for users of our shipped releases (though many of them are capable of such). While it's not really by design, it's often a convenient side effect that the annoyance of building KDE from HEAD means that the users *are* more technical, and very often developers.
There's also kind of the assumption that isn't always true of "If more people use it, it will be better, right?" Really that's only true up to a point, again, at this point in the release cycle. There are probably a few hundred people running KDE HEAD at the moment; normally that's quite enough to notice major bugs, assuming that the developer isn't already aware of them. I think there's a general shift from "Yes, I know -- I'll try to get around to it soon-ish" to "I think I got all of the important bugs fixed, let me know if you find any others" when KDE gets to the point in the release cycle where we ship a beta.
There's also been some talk of giving out these CDs to journalists or at trade shows -- this idea really scares me. The unitiated don't really understand, "Oh, it ate all of my email -- oh, but right -- it's just the developer's version" or "Konqueror doesn't work / render web pages at all." (The former I've had happen -- though not recently -- running HEAD; just recently for a few days Konq wasn't working at all over an autoconfigured proxy.)
I kind of dread the situation of one of the folks ending up with one of these CDs being a journalist or i.e. someone evaluating the use of KDE in their organization. It's rather different than showing CVS at such events, where at least there's someone there to explain why things are sometimes broken.
If you look back through the dot article you mentioned some of the responses were things like, nothing works, or has very obvious bugs, etc. In this case, I'm aware of said bugs -- they'll be fixed before the next release. In fact, they'll be fixed ideally by the time we ship a first alpha of 3.2, but at this point we're still 5 months from a release.
Basically to sum up -- I'm not fundamentally against the idea, but I think it requires some care in what it's used for. I think for translators, having something easy to throw in for demo-ing at a KDE show, etc, that this could be very useful. Also, I like the idea of having a different splash screen. Another possibility is giving it kind of a silly, but indicative name. As I recall it was the first KDE 2 alpha that was called "Krash".
(Hmm, this seems to be even less coherant than I usually am, ugh, too early for email. ;-) )
Oh, and I'm CC'ing core-devel so that if my opinion is completely different from the folks there too, that someone can just tell me to shutup and deal with it. :-)
(ed. [Russell Miller] Yes, I realize that this is kind of going against the idea of not wanting to make it publically known, but in that case, it shouldn't be discussed on a public and archived list. )
4. introducing brockenboring
25 Jun 2003 - 3 Jul 2003 (39 posts) Archive Link: "introducing brockenboring"
People: Stephan Kulow
Stephan Kulow said:
Currently our kdeinit support in the Makefiles lack as the kdeinit modules are installed in parallel to a binary linking against these modules. This has some drawbacks:
1. glibc's ldconfig doesn't cache DSOs that don't match the lib*.so* pattern, so starting konqueror won't be able to use the cache to find konqueror.so
2. (more important) this doesn't work at all on non-ELF systems (have you asked who the hell is using non-ELF these days? Mac OS X does)
Benjamin Reed once tried to get am_edit to create a shared library per KLM and then link both the KLM and the binary to it. As he failed, he tried the same for unsermake. Problem with unsermake is: automake users will fall behind without kdeinit support at all.
So we made a short brain storm session today and came up with the following idea: install a kdeinit module only and create in bin a link to a binary that will be kdeinit without kdeinit: "one binary to rule them all".
So here is the patch to do exactly that: introducing brockenboring
P.S. DSO == dynamic shared object,
KLM == kdeinit loaded module
It was very well received, though this editor must confess to having no idea what it is supposed to accomplish.
Subject: "Another treat"
Since I was late, I want to provide another treat. As again, I have a hard time deciding what, and as again, the costs for shipping spaghetti sauce are prohibitive. So, how about some cute kitties?
Aren't they cute? (http://www.blogjam.com/cute_little_kittens)
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.