After Martin Gräßlin’s excellent blog series for developers there is little I can add but agree on all points. I am currently adding versions to the existing open Plasma bug reports and that made me think of something:

When did YOU last test your own bug reports?

We have all submitted bug reports at some point, be this as a user, a beta tester or a developer. But when did we last follow-up on our own reports?

BKO makes it easy to follow up on my own reports as there is by default at least one saved search visible in the footer when I am logged in: “My Bugs”. Just a click on the link will show me a list of all bugs I ever reported that are still open.

As a user I try to do this on a regular basis, depending on the products I submitted the reports to, but at least on every version change. Since I am the one who reported it who else than me is the best person to actually test if the bug is still valid?

As a beta tester I of course test again when final is released.

As a developer I would probably test when I find time to, but at least on every major version change. So since 4.9 is around the corner this is a good occasion to put this on your ToDo list for the beta testing period

Oh, and I almost forgot:

The UNIX terminal UI has stood the test of time. Tools change, new tools crop up, certain tools are used commonly and others less so. I don’t see the familiar UNIX terminal concept becoming obsolete any time soon. The extensibility and sheer power that comes with it is the best thing since sliced bread.

Now, I like colors and pretty pictures. More specifically, I find it much easier to recognize a piece of information if it is colored in a meaningful way, this is the whole reasoning behind syntax highlighting in IDEs. Luckily some other people like colors and pretty pictures too, and with the power of Free Software they have come up with various ways to add some color to common UNIX-compatible shell tools.

Some of these are just wrapper scripts for existing tools, and some are entire rewrites with lots of added functionality. Some distributions already provide a somewhat colored environment. Some of them contribute to making my shell a much more colorful place.

cw

cw is a color wrapper for common UNIX commands. According to the project’s website, “it is designed to simulate the environment of the commands being executed, so that if a person types ‘du’, ‘df’, ‘ping’, etc. in their shell it will automatically color the output in real-time according to a definition file containing the color format desired.”

cw wrapper scripts do not modify the functionality of the tools involved, they just add colors, so they are a good choice even if you alias some of them to other, more sophisticated tools. Some of the added colors are just eye candy, and some of them are actually very useful.

htop

htop is an interactive process viewer for Linux. It is not just a wrapper for top, this is a completely rewritten and much more featureful program. I alias it in my .bashrc in place of top.

dfc

I have tried at least three colored replacements and/or wrappers for df, and dfc is the one I like best. I keep it aliased in place of df.

Other note worthy alternatives include pydf (also very nice) and cdf.

cdu

cdu stands for “color du” and it is a Perl wrapper for du. I keep it aliased in place of du.

ls++

ls++ is a tool I’m currently still testing. It is a wrapper for plain old ls, it uses common color schemes for file types (as used by the –color parameter of GNU ls) and mangles the output a bit to make it more relevant. I like how it shows permissions and dates.

Other programs

For many prominent toolchain elements there is a colorized variant or wrapper, such as colordiff, colorgcc, colorsvn, colormake and others. Some of them actually already produce very good colored output with the right options (without wrappers), like grep or tree, and are easily aliased in .bashrc to always show colored output.

Combine all that with a nice LS_COLORS in .bashrc courtesy of dircolors and a nice colored prompt and your shell will make you puke rainbows in no time

Lastly, as a bit of bonus content for Archlinux users I’d like to mention pacman-color and yaourt, they make pacman so awesome it’s not even funny.

Hi, I'm Matěj Laitl and this summer I've been accepted to GSoC for Amarok to work on statistics synchronization between various collections and scrobbling services such as Last.fm.

First, let me thank Google for sponsoring such a wonderful programme that lets me code on open-source during summer - instead of having to take boring jobs involving proprietary software. Now, about my GSoC project.

"Statistics synchronization, sounds boring" you say? Maybe, but I'll polish it to perfection and the second part of the project, two-way synchronization with Last.fm, is as far as I know unparallelled among audio players. My personal goal is to make the UI as intuitive as possible, not getting in the way. My mentor is Myriam, Amarok's famous bug wrangler, user supporter and community worker so I'm pretty confident it will go smoothly.

For start I plan to come up with a couple of use-case scenarios and further iron-out the overall design (is it just me or do others get the best ideas while in shower?) during community binding period. (since I'm already quite bound to the community) :-)

What are your expectations for Amarok statistics synchronization?

A little while ago Google published the list of accepted students for Google Sumer of Code 2012, and KDE got 60 students. If you are one of those 60, I wish you again a warm welcome to KDE.

I have put together a checklist of tasks and suggestions I advise you to follow during the community bonding phase. While you are not required to code until May 21 (end of the community bonding period), you are expected to get ready and be in good standing with your community. By now I suppose you have already contacted your mentor.

What follows also applies to Season of KDE students.

(1) Join the relevant communication channels.

KDE contributors do not just silently churn out code, they like to hang out a lot, exchange ideas and opinions. But since KDE pretty huge, different subprojects have their own communication channels. You should definitely join your subproject’s development mailing list (e.g. amarok-devel@kde.org for Amarok, digikam-devel@kde.org for digiKam, etc.) as an absolute minimum. I also strongly advise you to join your subproject’s IRC channel on irc.freenode.net, as many development discussions happen there (e.g. #kdevelop for KDevelop, #plasma for Plasma, etc.). You should also join #kde-devel and #kde-soc on irc.freenode.net. Your mentor will instruct you if there are other communication channels you should be aware of.

(2) Get acquainted with KDE’s infrastructure.

You should get a KDE Identity account and fill out your profile. This account works with most of the services provided by KDE, such as review board, wikis (Community and Techbase) and forums. You need to sign up separately for KDE’s issue tracker. You must then also apply for a contributor account to be able to commit code, please follow these instructions to do so.

(3) Get ready to blog.

Writing a blog is a great way to introduce yourself to the community and keep everybody informed on your progress. If you do not have a blog yet, consider starting one and having it aggregated on Planet KDE. I personally recommend WordPress which is also Free Software but you can use whatever platform you like. It is not mandatory but I think it’s a nice way to motivate yourself and bond with the community. Do not feel pressured to do it, but a few articles when you reach certain milestones in your project could be very nice.

(4) Learn the ways of the community.

Free Software communities work in certain specific ways which are sometimes very different from what a new Google Summer of Code student might be used to. To help you get up to speed quickly, Donnie Berkholz, Lydia Pintscher and Kevin Smith, Google Summer of Code administrators for Gentoo & X.Org, KDE and XMPP Standards Foundation respectively put together a very good article on the DOs and DON’Ts of Google Summer of Code for students. If you are new to KDE I consider this article a required reading assignment before starting your work. It is short, easy to read and to the point, and every word of it applies to your situation as Google Summer of Code students at KDE. For more information on getting involved with KDE specifically, I highly recommend the Free manual KDE Dev Guide, a step by step introduction to KDE for new contributors. A much more complete resource on getting involved with Free Software is Open Advice, a Free knowledge collection from a variety of prominent Free Software contributors.

(5) Talk it through.

You are not required to code for almost a month until the coding period begins, but work on your project starts now. Plan ahead. Do analysis and design. Make sure that if there’s any potential obstacle in your project, it comes up as soon as possible. Set aside a few hours and schedule meetings with your mentor to discuss the fine details of your project and iron out the kinks. It’s best if such discussions are held in the subproject’s IRC channel to allow all the interested parties in the community to contribute. Be ready to submit regular updates to your mentor once you start coding. KDE Google Summer of Code administrators strongly recommend weekly updates to the subproject’s development mailing list, but the exact way you do this is up to your mentor.

This year KDE has accepted 60 Google Summer of Code students. We are happy with this number, it is more than last year, and I’m sure these 60 students will make a great contribution to KDE as a whole.

But this number is still a hard limit: we had to say no to many brilliant proposals. The selection process has not been easy, and we had to make a lot of tough choices. KDE definitely has the mentoring capacity for more than 60 students at a time. So while we cannot come up with more Google Summer of Code slots, we can still make our mentors available through a similar scheme: Season of KDE.

What is Season of KDE?

Season of KDE is a community outreach program, much like Google Summer of Code, hosted by the KDE community. It is meant for people who could not get into Google Summer of Code for various reasons, or people who simply prefer a differently structured, somewhat less constrained program. Season of KDE is managed by the same team of admins and mentors that take care of Google Summer of Code and Google Code-in matters for KDE, with the same level of quality and care.

Who can take part?

Everyone can apply for Season of KDE. We give preference to those who have applied for Google Summer of Code and to students, but we will gladly consider applications from anyone.

What do I get out of this?

A great summer working on a really cool KDE project and gaining valuable experience. If you complete your project successfully you also get a T-shirt, a certificate, and maybe a few other goodies.

How do I apply?

If you are serious about it and have already contacted the relevant KDE subproject to discuss your proposal, fill out the Season of KDE application form and we will get back to you.

What is the timeline?

The timeline is up to you and your mentor. We advise you to stay as close to the Google Summer of Code timeline as possible. The only hard constraint is the application deadline: you apply through the application form before May 7, 2012 at 19:00 UTC in order to be eligible for participation.

Do I need to have a mentor before applying?

It is preferred. Ideally, you should contact a KDE subproject well before applying, ask for feedback on your idea if you have one, and request a mentor directly. A list of KDE subproject contacts is available on the Google Summer of Code 2012 ideas page. You can also apply without a mentor and we will try to find one for you.

Do I need to have a project idea before applying?

It is preferred. If you do not have one we will try to find one for you. Keep in mind that the KDE community is pretty big, so you should at least have an idea of which KDE subproject you wish to work on.

Do I need to write a proposal like in Google Summer of Code?

No, but we would like to see a brief project plan describing what you will be working on.

Is it only for coders like Google Summer of Code?

We are willing to consider non-coding projects as well, but you should definitely get in touch to figure out the details beforehand. The KDE Community Wiki describes ways to get involved with KDE that do not require coding.

I applied for a project in Google Summer of Code but another student got selected for it. Can I still work on it?

Maybe, but likely not. You should ask the mentor that was assigned to your idea. We can try to find something related for you if you want, or something completely different. Let us know what you wish and we will do our best to accommodate your request.

Is this an extension of Google Summer of Code or connected to Google?

No. While Season of KDE is in many ways modeled after Google Summer of Code and administered by the same members of the KDE community, it is completely independent from Google Summer of Code and has no connection to Google whatsoever.

—

For further questions feel free to join our IRC channel #kde-soc on Freenode or email the admin team at kde-soc-mentor-owner@kde.org.

In the past four years we had in order 1, 4, 8 and 20 successful Season of KDE students. We like to think this says something about how welcoming, helpful and fun the KDE community is. Our goal for this year is at least 30

Are you going to be one of them? You should be!

Google has just published the list of student proposals that have been accepted for Google Summer of Code 2012.

This year KDE received more than 200 proposals. 192 of those are valid and have not been withdrawn. The general quality level is very high, and most of those 192 proposals are very good. Google has allocated 60 student slots to KDE, which means that this year we are able to accept 60 Google Summer of Code students. The trouble is that we got a lot more than 60 good proposals! During the past few weeks the GSoC admins and mentors of KDE had to make some really tough choices.

If you are a student, you should have received a notification about the state of your proposals via email. Either way, you can check the status of your proposals on Google Melange.

Accepted into Google Summer of Code?

Has your proposal been accepted by an organization? Congratulations!

Has your proposal been accepted by none other than KDE? Awesome! This means that you will be spending your summer hacking with us. On behalf of the KDE community, I wish you a warm welcome! The selection process was hard and competitive, but if your proposal has been accepted it already means that we think you are the very best. Feel free to brag about it a bit, you’ve earned it!

I will write another blog article shortly on the next steps for accepted Google Summer of Code students.

Not accepted into Google Summer of Code?

If on the other hand your proposal has not been accepted, you are still very welcome to hack on KDE! Note that I never used the word “rejected” because I do not consider a proposal that has not be accepted for Google Summer of Code as something that’s unwelcome or unworthy for KDE. Many factors come into play in proposal selection which do not depend on the skill set of a student, including slot availability and mentor availability. We had to say no to quite a few brilliant proposals.

For those students whose proposals have not been accepted for Google Summer of Code who still wish to contribute to KDE in a guided, mentored way this summer, KDE hosts the Season of KDE program. Season of KDE is much like Google Summer of Code: while the student doesn’t get paid, he does get a mentor and a T-shirt, and he gets to hack on KDE for the summer and beyond. My first summer with KDE was as a Season of KDE student, and it was a very rewarding and enlightening experience. Season of KDE will be officially announced shortly, stay tuned

Some other organizations also host programs similar to Season of KDE for students who did not find a place in Google Summer of Code or simply prefer a differently structured program. Such programs include Haiku Code Drive (not confirmed yet for this year), illumos Students (not confirmed yet for this year), Umit Summer of Code (not confirmed yet for this year), X.Org Endless Vacation of Code, Ruby Summer of Code and possibly others. All of these programs allow you to work on really cool software with a mentor over a longer period and create something you can be proud of. Other communities will likely also be willing to provide guidance if you contact them directly, so don’t be shy

Little introduction first: I'm a student of theoretical computer science from Prague/Czech Republic and I've started contributing to Amarok last autumn by fixing some of its (mainly iPod-related) bugs.

It turned out that maintaining the iPod collection plug-in was rather painful due to its complexity that accumulated over time - and I got motivated to rewrite it from scratch by Amarok's Bart Cerneels. The effort is now over. Welcome the all-new iPod collection plug-in! (supports iPads and iPhones, too!)
Mandatory screen-shot of the rewritten iPod collection plug-inWhat does the rewrite bring? Well, working playlists, transcoding, multiple concurrent transfers, working stale & orphaned tracks detection and elimination plus many more enhancements and bug-fixes. Thanks to the rewrite, some bugs in USB Mass Storage collection got fixed, too.

You'll get all these goodies with Amarok 2.6, which is slated for release in a month or (rather) two. But if you're brave enough, I encourage you to compile Amarok from source using Mamarok's awesome guide and try it now! Please report any bugs you find to KDE bugzilla and if it works, send me a screen-shot of the iPod Device Configuration dialog so that I know how it looks with models I don't have.

iPod collection plug-in is only tested on Linux and won't probably work out-of-the box on other platforms. There is a hope for Windows users, there seems to be an older version of the needed libgpod library in KDE on Windows repositories. It should be possible to port the newest version, 0.8.2, too. Have fun!

Prospective Google Summer of Code 2012 students.

This is a friendly reminder that the student proposal submission period closes in 3 days.

If you are still working on a proposal, or if you have prepared a proposal but you have not submitted it to Google Melange yet, you better do it very soon!

Good luck

Attention prospective Google Summer of Code students: the student proposal submission window has begun.

This means that if you haven’t contacted the relevant KDE subproject and/or mentor and submitted your proposal for review, it’s high time to do so. If you have already gotten feedback and you think your proposal is in good shape, you’re encouraged to officially submit it to Google Melange.

Submitting early means your proposal might get more attention

Mentors: interest from prospective students has been high, and we’ll need to match those students with mentors. Offering more mentors might increase the number of student slots we get from Google, so if you’re an established KDE developer and you’re interested in giving a helping hand during Google Summer of Code, please sign up to be a mentor on Google Melange as soon as possible.

I’m happy to announce that KDE has been accepted as a mentoring organization in Google Summer of Code 2012. This is our 8th consecutive year. Congrats to all accepted organizations, and a big thanks to everyone who helped to make this happen for KDE!

Students. Now that you have a list of accepted organizations, it’s time to start working on your proposal. KDE maintains an ideas page which is an excellent starting point, and don’t forget to check our student guidelines. I’ve also prepared an article a while ago with a few tips on how to structure your proposal.

You can come up with your own idea or base your proposal on something from the ideas page, but either way it’s very important that you get feedback from the team you wish to work with well before the submissions deadline. If you have general questions about getting involved with KDE as a Google Summer of Code student you’re welcome to ask on our IRC channel #kde-soc on Freenode, or join the mailing list kde-soc@kde.org. For questions about a specific idea please contact the relevant team (subproject) directly.

Finally, make sure to keep an eye on the official Google Summer of Code timeline – those deadlines are always closer than they seem

Mentors. Now that we know that KDE has been accepted, it’s time to get ready to mentor some students. If you wish to be a mentor your next steps should be:

1. subscribe to kde-soc-mentor@kde.org,
2. sign up on http://www.google-melange.com and apply as a mentor for KDE,
3. contact one of the admins to approve your requests.

For questions you can reach the admin team on #kde-soc or at kde-soc-mentor-owner@kde.org.

And most importantly, in the following weeks you’ll be contacted by prospective students with questions and feedback requests for their proposals. It might take a bit of time and you might get questions with very obvious answers. Please be patient and keep an eye on the timeline

To help you through the process I’ve updated last year’s KDE GSoC process flowchart, courtesy of Lydia Pintscher.

 

In a few weeks students can begin submitting their applications for Google Summer of Code 2012.

KDE is applying to be a mentoring organization again this year, and I’ve already been contacted by several students looking to do a Google Summer of Code project with KDE (and specifically Amarok in my case). Prospective Summer of Code students usually have lots of enthusiasm, and they often write great proposals with little or no help, but sometimes these proposals might not be structured so well or lack key information.

I’ve been a Google Summer of Code student with KDE three times (four if you count Summer of KDE) so I’ve been in the very situation prospective Summer of Code students find themselves right now. I’ve also been on the other side of the fence: I haven’t been a Google Summer of Code mentor yet, but I have mentored Google Code-In students and I’m a professional software engineering instructor (since 2008), so I like to think I can relate with both students and mentors in this case.

This post is for students who wish to take part in Google Summer of Code.

Google Summer of Code is a kind of like a scholarship program, and a very competitive one: if you get picked, you’re one of just a thousand students in the whole world (1075 last year, 51 of those with KDE) who get to spend their summer hacking on Free Software while learning from the very best hackers, and get paid for it too! In order to do that, you need to submit an application to Google. An application is essentially a bunch of information you enter in a form, the most important part of it is your proposal.

A Google Summer of Code proposal is a document, it can be rich text but it’s best to consider it a plain text document because the web application that handles proposals has only basic formatting features.

The KDE community maintains a wiki page specifically targeted at Summer of Code students with very useful information on how to get started. Read it. Really, read it, please. Yes, all of it Done? Great! Assuming you’ve gone through points 1-3 of the Recommended steps list, it’s time to prepare your proposal.

Writing a good proposal is not easy, especially if you’re a student making first contact with an organization, in this case your proposal is your best advertisement. You have to convince the organization (or at least some key people inside it) why YOU are the right person for the job! What follows applies to KDE, but it should work for other organizations as well.

I used to structure my proposals the following way (worked well 3 times). It’s not a rule! You can structure your proposal otherwise, but I think this is a good guideline if you need some inspiration:

1. Introduction. Every software project should solve a problem. Before offering the solution (your Google Summer of Code project), you should first define the problem. What’s the current state of things? What’s the issue you wish to solve and why? Then you should conclude with a sentence or two about your solution. This is somewhat like an elevator pitch.
2. Project goals. This section should again be short and to the point, and it might be a good idea to format it like a list. You should propose a clear list of deliverables, explaining exactly what you promise to do and what you do not plan to do. “Future developments” can be mentioned, but your promise for the three months of Google Summer of Code term is what counts.
3. Implementation. This section can be longer and more detailed. You should describe what you plan to do as a solution for the problem you defined earlier. You don’t need to provide a lot of technical details, but you do need to show that you understand the technology and illustrate key technical elements of your proposed solution in reasonable detail.
4. Timeline. This section is easily overlooked, yet it’s arguably more important than the previous section. With the timeline you show that you understand the problem, have a solution, and that you have also broken it down into manageable bits and are have an actual plan on how to approach it. With this section you set expectations, so don’t make promises you can’t keep. A modest, realistic and detailed timeline is much better than a timeline that promises to move mountains. Mentors can spot unrealistic timelines.
5. About me. If you’re done with the other sections this will be a piece of cake. Just put down your contact information and write a few sentences about you and why you think you’re the best for this job. It’s ok to brag a little

Overall, submit your proposal early, keep it short but include all the necessary information. Get it reviewed by the right people in the organization, well before submitting it to the Google Summer of Code web application. In KDE’s case you should submit your proposal to the contributors’ mailing list of the relevant subproject as published on the ideas page. I can’t stress this enough: get feedback. Organizations want good proposals and good students, and are usually eager to help you improve your proposal. Just write a brief and informal email, attach your proposal and ask for feedback. No need to write “Dear Sir” and such, we’re cool

I hope this advice proves useful. We have also gathered some accepted proposals from past years, you might find them useful as inspiration.

You can submit more than one proposal to the same organization or different organizations to increase your chances, but don’t overdo it: quality is better than quantity.

Good luck!

During 2 months a couple of students aged between 13 and 17 have been helping to solve KDE tasks during the Google Code-In contest. As last year I did mentor a few of them, 19 to be precise. To give you a short update on how much work was done, here comes a list of their achievements:

 

• Number of tasks: 34

• 22 KDE bug triaging tasks (9)
• 5 Amarok wish-list cleaning tasks (5)
• 5 Amarok Userbase Manual update tasks (5)
• 2 Amarok webpage creation tasks (2)

2 Students also worked on different tasks, just in case you wonder why the numbers are different here Now 34 tasks seem little work, but the numbers behind the tasks are quite impressive:

• Amarok wish-list cleaning: The task consisted in installing the latest Amarok 2.5 version and testing 50 wishes to check if some might have been implemented and forgotten to be closed. There was a total list of over 450 wishes to test, and indeed all 459 wishes were tested!
• Amarok Userbase Manual update: it consisted in going through all chapters of the current handbook and update it to version 2.5, changing text and screen shots.
• KDE bug triaging tasks: the most impressive of all, as the students did triage over 750 bugs, finding many duplicates and even already solved ones and help reducing the bug count considerably.

All this work would not be possible if KDE and Amarok were not Free Software as it empowers the users and the developers alike and gives great opportunities to students to improve their skills. That is just one of the reasons I love Free Software

I'm happy to announce that we will have a KDE 4.8 Release Party in Ulm (Germany), on January 27.

The last party in Ulm was a blast, so we decided to repeat the event for this release as well. We will provide some finger food, live streaming, and plenty of space for having fun. For the details please see here, and add yourself to the list if you'd like to come:

KDE 4.8 Release Party @ Ulm

See you there!

Amarok 2.5 "Earth Moving" has just been released. So now it's time to have a look at all the exciting new features, as looking at bugfixes (which are important for sure) can be considered boring for a blog. ;-)

For Amarok 2.5 I have been working on integrating the Amazon MP3 store. The aim is to integrate it like any other collection. And as you are about to see we are already quite close.

You can find the service by fist clicking Internet in the Media Sources panel...

...where you can select MP3 Music Store.

And here we are. The service should have asked you for your location, as mp3 downloads sadly are not available worldwide but only in selected countries. And at the moment you are only allowed to download songs from your local store.

The service first loads some recommended albums (the entries on the top with the disc icon) and songs (below, with a musical note as icon). I am going to use that view now to present you some basic features. For example you can add a track to your playlist, as if it was part of your local collection. Be aware that Amazon does not offer complete previews, but 30 second snippets:

The service automatically loads the album cover of a song and shows it in the playlist. For some tracks this does not yet work, but that should be fixed in some days:

You can add tracks as usually using drag and drop, the popup dropper that fades over the context area or by using the context menu, which offers some more actions:

For tracks you can not only add the preview to the playlist but also search for the album the track is on and of course add it to your shopping cart.

Albums also allow searching for their contents:

The result might lool like this:

Finally i also added nice tooltips, so you can easily disinguish the same track from several albums in different versions:

When adding a track to the shopping cart you get a small notification below the service:

And of course you can search for whatever songs, artists, albums or audio books you like:

Our shopping cart, you can call it by pressing the button below the service,  is quite basic, but works fine:

Removing items ia a matter of pressing the delete key or calling the context menu of an item:

The item is then being removed, the shopping cart value updated:

Finally pressing "checkout" in the main window or the shopping cart opens the Amazon site in your default browser, where Amazon asks you for confirmation to really add these items to your shopping cart:

Sadly due to API limitations this does not work that easily for Amazon.com.

For downloading the actual tracks you need the Amazon MP3 downloader, Clamz or Banshee. Our own downloader will be ready for Amarok 2.6.

And of course Amarok gets a share of the profits made by this service.

This concludes our short tour. Have fun rediscovering your music! :-)

If you have ever wondered why some KDE folks are blogging less frequently now, the reason could be that they have switched to G+. Many FOSS and KDE people are now posting regularly on G+, among them Thiago, Linus Torvalds, Rob Malda of Slashdot fame, Glyn Moody, Trever Fischer, Harald Sitter, and myself.

What makes Google+ so attractive? Basically it combines a social network, quick status updates like Twitter, and blogging, and it's far quicker to do than traditional blogging. As opposed to Facebook, which I am no longer using, its UI is very minimalist, and the "Circles" feature makes it easy to select your target audience. Most of my contacts on G+ are FOSS people and work mates, and I rarely get "Friendship" (what does this mean anyway?) requests from people that I don't know.

You might like or dislike this trend, but it's a fact. Many of my posts on G+ are technology related, but not all of them. Most of the time, my posts are "public", so you can read them without having an account. This is my feed on Google+ (if you check my contacts, you will find many KDE people):


https://plus.google.com/u/0/102602725322221030250


Is this trend worrying, a good thing, or simply a new technology that we must accept?


Update: This is an interesting (public) article on the benefits of blogging on G+:

https://plus.google.com/112546833633391090642/posts/1fkCLdAFGuT

Back in June, an event was held in Berlin called the Qt Contributors' Summit. This was such a success that the team decided that it should not be the last time something like that happened. So, to further this success, Nokia's Qt Frameworks Division has offered KDE a whole day of unconferencing at the Qt Developer Days in Munich later this month.

If you wish to take part in furthering the collaboration between KDE and Qt, and indeed other projects, then join the Qt Contributors' Day on Monday the 24th of October at the Dolce Munich Unterschleissheim. To join in, send me an email at admin@leinir.dk to that effect

You don't have a ticket to Developer Days, you say? Well, not to fret! The KDE e.V. has been given a bunch of tickets to be given out to community members. To get your hands on one of these tickets, give me an email at admin@leinir.dk to inform me of this.

Please note! If you decide that you want to join us, get in touch with me BEFORE the end of this week! (i.e. before Sunday the 9th, which is when i send off the list of people requesting tickets and the like to the e.V. board for evaluation).

So - come to the Qt Contributors' Day at Developer Days 2011 in Munich, and let's make this thing epic! Qt 5 is ahead, and with the launch of the Qt Project, we have more to say than we ever did before!

Hello World!

This is my very first *Amarok* specific blog post. Yay!

(Okay, admittedly I did not really blog at all since now. This will change now, of course!)

As you may know, I've been a rather semi-active Amarok contributer until now, hacking Amarok's codebase to improve the User Experience. My major *feature* contribution is the KNotify backend in Amarok (which of course is not the most crucial part of Amarok). Other than that I was mostly fixing bugs noone cared about or exceeded the patience of the average Amarok developer when trying to be solved. I think there's going to be more activity on this blog now, since I seem to get involved in Amarok more and more these days (which is exciting).

The past week I've been at Randa, the most important KDE Sprint this year, I guess.  To work on Amarok and KDE Multimedia in general. See http://community.kde.org/Sprints/Randa/2011 for hints an information about this event. The most important aspect of the meeting was the Platform 11 meeting of course, where the future of KDE with regards to Qt's Open Governance Process was discussed. This however, is not part of this blog, as I was not really involved in that discussion.

Let's talk about the work spent in Amarok land during the spring in Randa. We (mainly Mamarok and me) managed to close about 92 bugs according to her statistics. Of course most of them were duplicates or already fixed bugs by other commits. However, with a rough estimate: I think I managed to *fix* (as in: fix by committing something) about 10 more or less severe bugs and quite some other annoyances/glitches. Currently, our bug count in bugzilla (bugs.kde.org) is down to 210, an impressive good rate per LOC in open source software with a huge code base like Amarok has. This number refers to the currently open "malfunctions", e.g. no wishes or bugs marked with WAITINGFORINFO (see: https://bugs.kde.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=al...).

The Randa sprint has been an adventure this time which involved meeting new friends and meeting old ones. During the event Bart and me managed to work quite focussed on some issues regarding Amarok without being too distracted by other stuff. That was a really nice opportunity.

The list of commits that went into Amarok by me during the Randa sprint is listed here (42 commits during ~7days):

* e7666c2 - Minor: Fix typo in ChangeLog (2 days ago) <Kevin Funk>
* a4f56ea - Minor: Reduce header dependencies (4 days ago) <Kevin Funk>
* f716da8 - ChangeLog++ (Browser backgrounds) (4 days ago) <Kevin Funk>
* 7a39afb - Apply background images to the various browsers (4 days ago) <Kevin Funk>
* 3df0c45 - Minor: Collections: s/Counting/Counting.../ (4 days ago) <Kevin Funk>
* 83533cb - Add scripting interface for KNotify (4 days ago) <Kevin Funk>
* e43a711 - Use warning() for DEBUG_ASSERT (4 days ago) <Kevin Funk>
* 9320d5f - Pushing an example use of DEBUG_ASSERT (5 days ago) <Kevin Funk>
* 8737ace - Add another debug helper: DEBUG_ASSERT(cond, stmt) (5 days ago) <Kevin Funk>
* c8ef564 - Reset playlist error counter after match (5 days ago) <Kevin Funk>
* c4cceaf - Possible fix for crash in CV (5 days ago) <Kevin Funk>
* df9ec60 - Minor: Reformat code (5 days ago) <Kevin Funk>
* 01ed71d - Fix possible crash in VideoClipEngine (5 days ago) <Kevin Funk>
* fbbb47f - LyricsApplet: Disable scrolling when editing (5 days ago) <Kevin Funk>
* dfbf424 - Minor: Simplify some API in Albums applet (5 days ago) <Kevin Funk>
* 9aa81ce - Fix invokeMethod call to non-existent slot (5 days ago) <Kevin Funk>
* ed5448b - Minor: Remove annoying debug output (SqlRegistry) (5 days ago) <Kevin Funk>
* d21bab5 - Fix playlist tooltip getting too tall (5 days ago) <Kevin Funk>
* cb86a84 - Make equalizer keywords (dB, kHz, ..) translatable (5 days ago) <Kevin Funk>
* fbb54ff - Remove unused (+useless) PNGs from src/data (5 days ago) <Kevin Funk>
* 8098b22 - Unbreak Equalizer presets API a bit (5 days ago) <Kevin Funk>
* 471f0ac - Minor: Prettify ChangeLog (5 days ago) <Kevin Funk>
* 1170062 - Fix regression introduced by 34163f8 (5 days ago) <Kevin Funk>
* bb5c2f9 - Remove some outdated documents from docs/ (5 days ago) <Kevin Funk>
* 34163f8 - Make preset names translatable (5 days ago) <Kevin Funk>
* 66ef047 - Add script error reporting at runtime (6 days ago) <Kevin Funk>
* 34bbda9 - Minor: Improve debug output (6 days ago) <Kevin Funk>
* 82d102b - Fix "Happy" moodbar theme (6 days ago) <Kevin Funk>
* fcc420c - Fix crash by invalid scripts during stop phase (6 days ago) <Kevin Funk>
* 3157057 - Minor: Header/include cleanup (6 days ago) <Kevin Funk>
* 0406303 - Remove leftovers from a5628ac (6 days ago) <Kevin Funk>
* 6d93167 - Fix collection context menu items ordering (7 days ago) <Kevin Funk>
* f6799cd - Header cleanup starting from CollectionTreeView (7 days ago) <Kevin Funk>
* e902c44 - Minor: Rename hintlineedit(cpp|h) to HintLineEdit (7 days ago) <Kevin Funk>
* 76e9be8 - Fix strings in status bar (7 days ago) <Kevin Funk>
* 5eb2862 - Move the playlist length info into the playlist (7 days ago) <Kevin Funk>
* cae9d5a - Minor: Rearrange some code (8 days ago) <Kevin Funk>
* 8879afd - Remove outdated handbook/ directory (8 days ago) <Kevin Funk>
* 36ca680 - Remove stale OXYGEN file (8 days ago) <Kevin Funk>
* 48023de - Remove unused class ExpandingControlsWidget (8 days ago) <Kevin Funk>
* f524292 - Replace some other "LastFM" strings (8 days ago) <Kevin Funk>
* b72b933 - Fix crash when accessing The::statusBar() (9 days ago) <Kevin Funk>

 

PS: We (Team Amarok) also managed to win the Randa foosball cup 2011, by rocking all the other teams. Team Amarok consisted of Bart and me. Evidence can be found in the picture attached picture!

 

     

PPS: A nice picture collection of the event in Randa can be found here: https://picasaweb.google.com/valorie.zimmerman/RandaSwitzerlandKDESprint - Thanks to valorie for sharing and commenting all the pictures!

AttachmentSize Randa_2011_foosball_scoring_board.jpg839.59 KB Banner_NilsFurrer_went_to.png31.46 KB

At various points the sysadmins have gotten a request to have repository tarballs made available. The idea is that some repositories can be very large; I believe test runs of the KOffice conversion produced a repository that is 350MB in size. Once you get this down to your system, updating with new refs is relatively fast, but what about that first part? What if you’re on a slow dial-up link somewhere (as some of our contributors are) and/or only have access to the Internet sporadically?

A solution to this is to provide repository tarballs to users which contain a snapshot of the repository. Once downloaded and expanded, you have a viable git clone; run a pull and you’re done (it’s pre-configured to fetch new refs from anongit.kde.org). Actually, run the init script and then a pull; to keep the tarball size as small as possible, it doesn’t include a checked-out working tree, only the .git directory and a tiny script that will a) delete itself and b) check out the working tree.

Now, the idea is to be able to start downloading at one time and to finish it later. The key here is that HTTP file transfers are resumable, so if you start downloading the tarball you can pick up where you left off. However, there was a question — how to be able to show a consistent link on Projects without a priori knowledge of tarball characteristics (since we can’t know any from within Redmine). In Redmine, all we could really do, without massive hackery, is display a statically-named tarball — in this case, it always ends in “-latest.tar.gz”. You can see this at https://projects.kde.org/projects/playground/network/aki/repository or any other project’s repository tab — note the “Tarball” checkout method.

This means however that the client needs some way of knowing whether it’s the same tarball or has been regenerated since. An easy way to do this is to use the If-Unmodified-Since header; however, the web server in use currently doesn’t support this (I checked and the author didn’t believe it was widely used; I pointed him to cURL/libcurl). The other problem with this approach is that it’s not very visible to the user.

So, I first changed the script such that the tarballs being generated weren’t actually named *-latest.tar.gz, but instead that they had more descriptive names and had a -latest.tar.gz version symlinked to the actual tarball. I then wrote a simple web service that the web server proxies to whenever it finds a “-latest.tar.gz” file being requested. This service resolves the symlink and redirects the client, so the user sees immediately what the name of the actual file is. For instance, right now a tarball of the aki repository via http://anongit1.kde.org/aki/aki-latest.tar.gz forwards to http://anongit1.kde.org/aki/aki_20101202050239_sha1-5f866b3a42872f8fd54adcf30bcb8a3a79d02542.tar.gz

Note the components of that filename: the name, the date/time stamp (to the second), “sha1″ indicating that that’s the algorithm to check the hash against, and the hash of the file for easy verification of the completed download. This should make it both easy for the client and the user to verify that it’s the same file, in addition to making it easy for the user to verify the integrity of the full file since they can check the sha1sum against the filename itself.

I think this provides a pretty nice solution to the problem.

Two quick updates on Git stuff:

First, we now have three anongit servers in rotation. We could probably make do with 0.25 of a single anongit server at the current load, but that will change quickly once kdelibs and co switch over from SVN, so it’s good to be ready.

Second, the generated commit URLs will always be given with the full commit hash, but the commit resolver now supports using partial hashes in case you want to shorten it yourself. For instance, you could manually change the commit URL http://commits.kde.org/amarok/cf17de39f9021064a713db965487be6e3d75a186 to http://commits.kde.org/amarok/cf17de39 to give out a shorter URL.

That’s all; if you were in the States I hope you had a good Thanksgiving.

I haven’t blogged about updates to the Git infrastructure for a while and it’s *long* overdue, so here goes. There’s a lot and I don’t have much time so I’ll keep things brief. Credit for these items go to the sysadmin team as a whole plus Sitaram (the Gitolite author)…

anongit servers

We now have two anongit servers (the second one will be coming online on Monday or so — it’s 95% done). It is very likely that git:// and http:// protocols will be restricted to the anongit servers for better load balancing, so if you have been using git://git.kde.org/… as your clone URLs, please switch those to git://anongit.kde.org/… URLs. Wait, did I just say http?

http protocol support

The anongit servers support pulling/cloning via http. This is using the newer Smart HTTP support in which the Git protocol is run over HTTP via a special server. All pushing must be done via SSH (port 22 or 443) on git.kde.org.

trash/destroy

There are now two systems of deleting your personal clones/scratch repositories.

• unlock/destroy: You can destroy a personal repository, at which point it is gone forever; however, for safety you are now required to run the “unlock” command on the repository first.
• trash: You can trash a personal repository. When you do this, it will be saved for 28 days in case you change your mind. You can use the “list-trash” command in order to see the repositories you have in the trash.

More details can be found in the Git(.kde.org) Manual.

who-pushed

There is now a “who-pushed” command that, given a SHA1 and a repository, can tell you what user pushed that SHA1 to the repository. This is essential for auditing, since commit authorship information can be faked. Now, if a problem arises, we at least can know who introduced that malevolent commit into the public repository.

Repository nicknames

Remember my last post about short Commit URLs? One thing I wanted — and was much requested — was a way to have a more friendly repository identifier. Now they exist. If a friendly identifier exists for a repository, it will automatically be used in the commit URL that is generated. If you want a friendly URL, let the sysadmins know. (We need to figure out a way to make nice names for repo names longer than 8 characters — or just remove that artificial restriction.)

Clones path change

When we first started out, clones would live somewhere like clones/amarok.git/mitchell/myamarok. Why the “.git”in the middle  (we were asked a lot)? Because the path was meant to match the actual name of the repository as it exists on the server.

The reason for *that* is that Git uses a “.git” suffix on repositories that are bare, to make it clear that it’s a Git directory. However (as we found out from Sitaram), this is not supposed to be user-facing, which is why if you use a Git URL with “.git” at the end of it, it’s dropped in the folder that actually is created on the client. So either the path has to lie about the original path on the server, or the client/user has to be made aware of it when it doesn’t really need to be.

What we ended up doing is removing that “.git” from the middle of the repo name (so now it’d be clones/amarok/mitchell/myamarok) and also took pains to ensure that when clone URLs are shown to the user, they are shown without a trailing “.git”.

At the same time, Sitaram made changes in Gitolite to better handle (in the various commands and in the built-in functionalities) cases where the user uses does or does not use the “.git” suffix so that it works correctly in each case.

Updated permissions on master repositories

Master repositories now allow users to create new branches; however, deletion requires the chosen repository manager(s) to intervene.

Updated permission granularities on personal repositories

Personal (clones/scratch) repositories now have a greater level of permission control settable by the user. (The git.kde.org user manual is not yet updated with this information.)

These are now the permission levels that the user can set, from least to most:

• All: everyone has read and basic write permissions on each repository
• Writers: writers can write new branches to the repository
• Managers: managers can also delete branches from the repository
• Dangers: people designated as dangers (to the repository!) can also rewind/force push to the repository
• Creator: the creator always has full rights

projects.kde.org tree view

If you check out the projects page on projects.kde.org (here) you’ll see that it now supports a tree view matching the structure of the KDE repositories. The URLs also match this structure.

projects.kde.org last activity indicator

On the same page (here) you’ll see that information about the last commit for that project is now shown next to each project.

…aaaaaaaaand we’re done.