Tux news - Linux ubuntu fedora gentoo gnome news » Kde

Feeds

66540 items (51620 unread) in 130 feeds

• planet.freedesktop.org (615 unread)
• Planet IM (275 unread)
• Planet Jabber (413 unread)
• Planet Mozilla (3838 unread)
• Planet OpenOffice.org - Developer News (1421 unread)
• Planet SLUG (1026 unread)
• Planet SUSE (2827 unread)
• sourcefrog (18 unread)
• what are we doing today, brain? (45 unread)
• Daniel's Journal (25 unread)
• TheMuso's blog (23 unread)
• KLEPAS.ORG (23 unread)
• kattegrot (38 unread)
• James Henstridge (15 unread)
• Das Blog - Latest Entries (14 unread)
• rwhitby.net
• hardy.dropblog (12 unread)
• Advogato blog for mtearle (10 unread)
• Madabar.techblog (1 unread)
• Joshua Hesketh's blog (12 unread)
• Random Thoughts: Simon Rumble (43 unread)
• Jeremy Visser (54 unread)
• jarich's Journal (33 unread)
• 文字馬鹿: A fool of words » Linux (1 unread)
• James Purser's blog (84 unread)
• people.samba.org/people/ (23 unread)
• Julien Goodwin (36 unread)
• Bend in the Weather (54 unread)
• Tony's Diary (44 unread)
• Etymon (25 unread)
• LawFont.com » kim (31 unread)
• Weblog (69 unread)
• Kristy A. Bennett blogs
• noogz.net (29 unread)
• blog.kfish.org (27 unread)
• Jason Parker-Burlingham (29 unread)
• Arjen's Journal (107 unread)
• John's Tidbits (12 unread)
• A2K v DMCA in Australia (33 unread)
• Michael Davies' Blog (55 unread)
• Too Busy For Words - The PaulWay Weblog (25 unread)
• sjh - mountain biking linux geek spice (82 unread)
• treacy.id.au
• The House of Commons (49 unread)
• gdt blog (19 unread)

Linux (11669 unread)

• Planet Libre (2120 unread)
• DLFP - Dépêches de page principale (303 unread)
• Slashdot (4222 unread)
• Planet Linux Australia (2977 unread)
• Planet Linux-to-go (180 unread)
• Planet Linux Indonesia (1386 unread)
• Planet Arch Linux (226 unread)
• Planet Linux - Linux and open source news (8 unread)
• Planet Arslinux (247 unread)

Gentoo (516 unread)

• Planet Gentoo (516 unread)

Debian (6571 unread)

• Planet Debian-FR (52 unread)
• Planet Debian (3261 unread)
• Planet Debian (3258 unread)

Fedora (5754 unread)

• Fedora People (5097 unread)
• Planet Fedora-Fr (657 unread)

Kde (2685 unread)

• Planet KDE (2425 unread)
• kdedevelopers.org blogs (260 unread)

Gnome (3577 unread)

• Planet GNOME (3577 unread)

Mandriva (396 unread)

• Planet Mandriva (396 unread)

MySQL (3238 unread)

• Planet MySQL (2806 unread)
• MySQL Performance Blog (135 unread)
• Planet MySQL (297 unread)

Apache (3436 unread)

• Planet Apache (3436 unread)

Redhat (90 unread)

• Planet Red Hat (90 unread)

Kde (5 unread)

Planet KDE

• 

  Stephan Binner (Beineri): First openSUSE KDE Team Meeting 2009

  Posted: January 6th, 2009, 11:27pm CET

  pTomorrow most people will be back from the holiday season, time to start again with the a href="http://en.opensuse.org/KDE/Meetings"biweekly IRC meetings/a of a href="http://en.opensuse.org/KDE/Team"the openSUSE KDE Team/a. This time we will look back to last year or rather to the a href="http://en.opensuse.org/OpenSUSE_11.1"openSUSE 11.1/a release shortly before Christmas and the biggest reported problems. And also, despite the a href="http://zonker.opensuse.org/2008/12/15/discussing-opensuse-112-schedule/"schedule discussion/a not being finished yet, we will start to collect and discuss a href="http://en.opensuse.org/KDE/Ideas/11.2"ideas for openSUSE 11.2/a./p

kdedevelopers.org blogs

• 

  First openSUSE KDE Team Meeting 2009

  Posted: January 6th, 2009, 11:27pm CET by beineri

  pTomorrow most people will be back from the holiday season, time to start again with the a href=http://en.opensuse.org/KDE/Meetingsbiweekly IRC meetings/a of a href=http://en.opensuse.org/KDE/Teamthe openSUSE KDE Team/a. This time we will look back to last year or rather to the a href=http://en.opensuse.org/OpenSUSE_11.1openSUSE 11.1/a release shortly before Christmas and the biggest reported problems. And also, despite the a href=http://zonker.opensuse.org/2008/12/15/discussing-opensuse-112-schedule/schedule discussion/a not being finished yet, we will start to collect and discuss a href=http://en.opensuse.org/KDE/Ideas/11.2ideas for openSUSE 11.2/a./p

Planet KDE

• 

  Sayak Banerjee (glade88): KDE Forums: Want to be a mentor?

  Posted: January 6th, 2009, 9:27pm CET

  pDo you think that you have significant amount of experience to work as a mentor at KDE forums? Then you should consider joining the team! Read on#8230;/p pstrongWhat do mentors do?br / /strongMentors are responsible for conducting a href="http://forum.kde.org/klassroom-f-71.html" onclick="javascript:pageTracker._trackPageview('/outbound/article/forum.kde.org');" target="_blank"Klassroom sessions/a. For those who aren#8217;t familiar with the KDE Forum klassroom concept, read a href="http://blog.sayakbanerjee.com/?p=114" target="_blank"this/a post.br / You will be conducting a #8220;Kourse#8221; (lesson) at the Klassroom area. The lesson can be something like #8220;Fixing XYZ bugs#8221; or #8220;Documentation kourse for project ABC#8221;. You will guide a team of #8220;students#8221; (who will apply for your kourse beforehand). Your motive will not only be to contribute to KDE but help them learn how to do so./p pstrongWhy are mentors needed?br / /strongWith the great success of the klassroom concept, we are looking forward to have more sessions (at higher frequency). For that, we would need more contributors who can undertake and organize sessions. Existing mentors are listed a href="http://forum.kde.org/groups.php?gid=13" onclick="javascript:pageTracker._trackPageview('/outbound/article/forum.kde.org');" target="_blank"here/a./p pstrongWhat all would you have to do?br / /strongAfter joining the mentors group, you will have access to the mentor team forums and moderational access to the Klassroom forum. You can start by posting a draft of the kourse you will be conducting, which can be reviewed by other mentors and forum staff. Once ready for shipping, your draft will be announced for public viewing and you can start with the kourse at the a href="http://forum.kde.org/active-kourses-f-75.html" onclick="javascript:pageTracker._trackPageview('/outbound/article/forum.kde.org');" target="_blank"Active Kourses/a area. Your kourse can be based on any of the following:/p ul liBug fixing and development in general/li liDocumentation and screencasts/li liAny form of KDE artwork/li liTranslations/li /ul pAt present, you would be handling a small team of 5-6 students, though this limit may go up depending upon the interested candidates and kourse popularity. After joining, you can also optionally have a #8220;Mentor#8221; badge for your username./p pstrongHow can I apply?br / /strongIf you are interested to contribute, you can send a PM to a href="http://forum.kde.org/neverendingo-u-3.html" onclick="javascript:pageTracker._trackPageview('/outbound/article/forum.kde.org');" target="_blank"neverendingo/a (requires registration on the forums) or find him on IRC: channel strong#kde-forum/strong, network emfreenode/em.br / In case you send a PM, don#8217;t forget to include a short introduction of yourself and your plans (if any) for upcoming kourses./p
• 

  Aaron Seigo (aseigo): bugs.kde.org

  Posted: January 6th, 2009, 8:53pm CET

  I work with bugs.kde.org nearly every single day.br /br /Most people who report bugs on it hardly ever visit it, and that's not a bad thing.br /br /Some people who do end up there are frustrated due to some problem they ran into and so show up a little less than happy. Most are congenial, however, which is nice.br /br /Unfortunately, there's still that familiarity gap. I have built up over the years a set of internal expectations around handling the bug system that I know are completely non-obvious to anyone who doesn't use bugs.kde.org often .. which is most of our reporters .. which leads to frustration. Everyone couple years I blog about this frustration. This one of those blogs.br /br /Sometimes I honestly think a "bugs.kde.org driver's test" should be a prerequisite to using the system. It would go miles to improving the quality of the reports. In lieu of that, here are some quicky notes on handling bugs.kde.org:br /br /ulbr /liiAlways/i include the version of KDE you are using. If you build from svn, then include the svn revision #. Otherwise, `kde4-config --version` is perfect./libr /liIf reporting a crash, provide a detailed description of what led to the crash. If reporting a functionality bug, describe the steps iin detail/i needed to reproduce the problem. If you don't know, just describe as much as you can about what you or the machine was doing at the time. These descriptions help us replicate your experience which is critical to solving many reported problems./libr /liIf you are reporting a crash, ialways/i include a backtrace. If it has lots of "unknown symbols" in it, though, it's not likely to be very useful and your description of how to reproduce will be even imore/i important. However, first consider reading a href="http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports"this how-to on creating nice backtraces/a and get a realy good backtrace for the report./libr /liDo inot/i upload backtraces as attachments to reports! Instead paste them into a comment. This lets us easily search the database for similar backtraces. It's easy to search through comments in Bugzilla, not so much so through random attachments./libr /liIf the bug is rendering related, include what the graphics hardware and driver version is. It may not be relevant, but it often is and will save a "what's your graphics hardware?" roundtrip question./libr /liIf the bug has a visual manifestation (e.g. you can see the bug itself or symptoms of it somewhere on the screen) consider taking a screenshot of it and attaching it to the report. Screenshots are often very, very useful to understanding bug reports. Pictures and a thousand words and all that./libr /liIf you can't reproduce the bug after a while, let us know. That's useful information./libr /liIf we ask for more information, try and respond as soon as you can. Some bugs are easier to fix at certain times than others, for various reasons. Helping us by being attentive is much appreciated. If you can't get to it right away, or if you feel the answer you have isn't a good one (e.g. you tried what was requested, and nothing happened) still report back with either a "I'll get to it when I can" or "I tried it and got nothing useful back". At least this way we know you're still there./libr /liDo not post to random bug reports unless your problem is the exact one in the original report. If you have a crash and your backtrace does not look identical at the top of it to the one in the report, do not add it to an existing report. If you have a similar sounding but not identical problem, do not add it to an existing report. File inew/i reports. Bugzilla lets us merge reports, but it does not let us take a single comment and break it out into its own report. I wish it did, but it doesn't. Yes, this is a shortcoming in Bugzilla, but it's one we have to live with. This means that if you just pile in new bugs into old reports, we end up with reports that are completely unmanageable. Eventually, I just end up closing those kinds of ruined reports and make everyone file new ones./libr /liWhich leads to: one problem per report. Yes, Bugzilla is not the fastest tool to use and so it can be tempting to just pile in 2, 3, 5 or sometimes even more issues into the same report. Don't. It becomes very hard to track which issues are fixed and which aren't. Again, this is mostly due to shortcomings in Bugzilla, but it's the reality we deal with. File separate reports for separate issues; and yes, even if it's two different issues on the same topic. ;)/libr /liWhenever you comment on a bug, the assignee(s) and the people on the CC list get an email with your comment in it ... ieven if the report is closed/i. So feel free to add comments to reports, someone somewhere will still get a notice of them./libr /liFixes will not appear immediately on your computer. You will need to wait until you update your installation to a version that contains that fix. Depending on when the fix is made and how you install KDE, this can even be many months time. This may sound like an obvious item, but many people seem rather surprised when I mark something as fixed with a commit to svn but the problem is still there on their computer./libr /liDescribe your problems thoroughly, but don't get too clever unless you've actually read the code. Way too often I get reports where the person has a pet theory about why something is happening and unfortunately the theory is dead wrong. At best it's just a waste of my time reading that part of the report, but more often it ends up confusing the report with some misinformation and worst case (which happens too often) the reporter gets so caught up in their idea of why the bug is happening that they end up describing that theoretical problem as opposed to what is actually happening. This risks confusing the bug triager, and often just means a long series of back and forth questions. If at all in doubt, just describe the problem as it manifests itself as thoroughly as possible. Leave the root-cause sleuthing to those with the code in front of them./libr /liYou don't have to suggest a solution. It is perfectly Ok to say "This doesn't work for me." and leave it at that. If there is a preferred way you'd like to see it happen, describe it in those terms: "I would prefer if ..". But as the reporter you don't ihave/i to come up with a solution./libr /liI hate the term "wishlist" because it makes it sound like something you'd like to have but probably won't get. I far prefer the term "feature request" because that's what it really is, and "feature request" lacks all the implications of "wishlist". Some people get really annoyed when I mark their report as "wishlist" and in one sense I don't blame them; if you didn't know any better it might sound like your report has just been brushed off. That's not the case, however: if the request is for a new feature or new functionality, as opposed to fixing existing functionality, it's a feature request not a defect report./libr /liDon't bother overstating the severity of your bug. It won't fool anyone. Seriously. =)/libr /liDon't bother linking to your favourite bug report from your blog, on web forums, on irc, etc hoping people will vote for it. When I see a bunch of people randomly showing up to vote on a report, I assume this is what has happened and ignore those votes. Such vote canvasing only distorts the statistical distribution of voting on bugs.kde.org and makes it impossible to distinguish between reports people actually, really want fixed and ones that someone has just done an effective job of campaigning for in online forums. ;) In general, I put far more weight behind how many duplicates a report has than votes./libr /liWhen it comes to feature requests, a judgment call is often required. That call belongs to the person(s) designing the software. If they decide against a feature, don't belabor the point by endlessly trying to convince them or getting angry with them. It doesn't help anything./libr /liSaying thank-you even once makes up for 10 mistakes made elsewhere. It's really encouraging when a reporter is civil, cordial and says "thanks" when the fix goes in. Dealing with reports on bugzilla is, quite frankly, not the sexiest thing in the world to do, so anything that makes it go a little easier and nicer helps./libr //ulbr /br /Probably not an exhaustive list, but there you go. Hopefully something in that list is useful to someone out there at some point in the future. =)
• 

  Aaron Seigo (aseigo): 4.2 RCs tagged, trunk is now 4.3.

  Posted: January 6th, 2009, 8:47pm CET

  Earlier today Dirk sent a message to the release team and KDE core devel mailing lists noting that KDE 4.2 is now a hre="http://websvn.kde.org/branches/KDE/4.2/"branched off of mainline/a and that the the first RC is being tagged. That means trunk is now what 4.3 will be.br /br /As I've been reminded a few times already today myself, that means we need to backport bugfixes made to trunk that we want to appear in 4.2. The svnbackport script in kdesdk was updated today to backport to the new 4.2 branch and makes the process of backporting your last commit trivial.br /br /The last few weeks leading up to a release are always exciting and nerve wracking for me. There are numerous details that always need to be worked out, though the project is getting better and not leaving things to the last minute. The promo team has been working on release materials since sometime in December, even. Hopefully that reduces the stress levels and burn out rates. =)br /br /In a couple week's time it'll be full throttle on 4.3 ..