Planet Amarok

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!

Our KDE-Windows team has been working silently in the background to present you a whole new experience: You can now use your preferred Desktop experience and Audio player on MS Windows, too!

Indeed, Amarok 2.5 is the first stable version we release on Windows, offering the same options as the already famous Linux version does. To quote Patrick von Reth, the developer who brought Amarok 2.5 to the MS Windows platform: “In 2005 when I first used Amarok on a Live CD and whished they would support Windows I never imagined I would be the guy who would help bringing it to Windows”.

As a special Christmas gift you can now use the KDE 4.7.4 software compilation on Windows as well. Although still not considered stable and suitable for production work, it is worth a try as it brings a lot of improvements such as the brand new Konversation IRC client 1.4 version, the personal finance manager Skrooge in version 1.1.1 to only name a few KDE applications and, as a technical preview, the speech recognition software Simon in 32-bit. You can get Amarok 2.5 as a standalone product or, even better, install it together with KDE 4.7.4 through the KDEWinInstaller.

Don’t hesitate and get your preferred Free Software on Windows as well

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! :-)

Akademy 2012 will happen from June 30th to July 6th in the beautiful town of Tallinn, Estonia. Mark the dates in your calendar and think about exciting stuff you could do there. A call for papers will be published in time.

Read more on the dot.

The Quarterly Report of KDE e.V. for Q3 2011 has been published. It gives an overview of all the important activities the e.V. supports like the Desktop Summit in Berlin and various sprints but also the annual general assembly and finances. It also contains an interview with me about why KDE rocks at mentoring. Check it out here: http://ev.kde.org/reports/ev-quarterly-2011_Q3.pdf

Special thanks to Carl, Claudia, Inu and Rob and everyone who helped them for working on an awesome report.

You can help make everything mentioned in this report happen by supporting KDE e.V. financially. Become a supporting member today and Join the Game.

 

 

I’m excited that KDE has once again been given the opportunity to work with a number of really awesome kids as part of Google Code-in 2011. Find out more about Code-in and the other 17 accepted organisations in the announcement.

This time Valorie, Sandro, Annma, Akarsh and Roger are helping me with admin duties. We’re looking forward to the flood

If you’re interested in taking part in Code-in as a student have a look at KDE’s preliminary task list. Those will be moved to the official place in the next days. The real fun starts on November 21st and then you can start working on the tasks. If you have ideas for tasks that you would like to work on but that are not on the list then please propose them either to a potential mentor or the admins. Be quick with this. We can’t add tasks again until Dez. 16th once the program started. Please also carefully read the eligibility requirements.

KDE mentors: If you still have task ideas please add them to the wiki asap.

Should you have questions feel free to ask either on the kde-soc mailing list or in the IRC channel (#kde-soc on freenode).

We’ve got quite a few tasks for Google Code-in now but still not enough on the wiki page: http://community.kde.org/GoogleCodeIn/2011/Ideas. Please help fill it. It needs to have a lot of tasks (at least 5 in each area) on Nov. 1st (org application deadline). I’m sure there are a lot more of those “oh man I wish I had more time to get this done one day” tasks. This is your chance!

For more details check my initial announcement. There are also more task ideas in the comments there that are looking for a mentor in case you are not very creative today

If you have questions please find me in #kde-soc on freenode.

 

PS: Please only add tasks with a mentor.

Every now and then we get the same complaints about bug reports again: Either it is a complaint by the user who feels her/his report doesn’t get enough attention from the developers or it is the developers who complain that there are too many bad and useless reports making them spending too much precious coding time on triaging bug reports.
Disclaimer: I am not a developer but do bug triaging, documentation writing and application testing.

I think personally that bug reports are an important feedback from the users, provided those reports are indeed useful to the developers. But what is actually a good bug report? I will restrict my explanations to KDE and its Bugzilla bug tracker, but this applies of course to all bug reports.

1. It should be about the most recent version available

I know that not everybody is updating their computer regularly, some people only do security updates which is probably well enough for their use case, but they should also be aware that Free Software is fast-paced and most developers are already working on newer versions and may even be some versions ahead. In general, bug fixes are not backported to previous version by the developers, simply due to lack of time and manpower.

If you use an older version you can still report it to your distribution if they provide support for it, though. Some distributions even do backports, but also rarely to older versions as most do not have enough resources either.
Don’t forget to specify the exact versions of the product and of KDE (available in the Help menu of all GUI applications).

2. It has to be reproducible

A one-time bug is not reproducible, so it is impossible to fix as the developers need to be able to reproduce it to test and search the location in the code where the problem lies. It is also very important to give a short step-by-step guide how to reproduce the bug.

3. The subject and comment must be in English, easily understandable, and searchable

If you can’t report a bug in English, please don’t. The KDE community is international and the working language is English as it is the one most people in the community understand.
We often get reports with subjects like “Doesn’t work” or ” Your application sucks, fix it!”. This is of course not very clear and highly subjective. For a bug report to be useful it must be well described so it can be searched in the database and so it is actually understandable by the developers.
The Subject should be a short sentence summing up the important points of the bug, for example “Product X crashes when clicking on Icon Y”.
You can and should give more details in the following comment, but keep it short and with a clear structure.

4. The report should be unique

Some bugs will hit many people so it is not unlikely that many people will report it. This leads often to duplicate bug reports which need to be eliminated and collected into one unique report. Knowing that more than half of the reports we get are duplicates this will of course cause quite some triaging work.
When reporting a bug a well written subject line will allow to find duplicates in Bugzilla quite easily. It is even easier if it is a crash as usually Dr. Konqi will suggest duplicates by querying the database. In doubt, don’t submit the report but ask in IRC, search the forum or the mailing list of the project if somebody has already seen it.
Bugzilla provides a very good advanced search query one can get used to quite easily.

5. If it is a crash, it should come with a valid backtrace

But what is a valid backtrace? Most distributions will strip the applications files of their debugging symbols to gain space, especially if they ship a CD and/or DVD of their versions. Those debugging symbols can be obtained separately and have file name endings like -dbg (Debian and Debian-based distros), -debuginfo (OpenSUSE) or -debug (Mandriva) for example. You will find more information and more distributions listed in this KDE Techbase summary.
Dr. Konqi will rate the backtrace quality with stars as you can see here:

As a general rule: do not submit crash reports that do not have 3 stars as something is missing. If you don’t have debugging symbols installed, Dr. Konqi will warn you and provides the opportunity to install them directly from within Dr. Konqi.

Of course, a backtrace should ideally always be posted in the comment and not as an attachment, so it will be searchable in the database. Hint: the important thread is the one that has [KCrashHeader] after the thread header, so you can most of the time strip the other threads.

6. Be available to give feedback if needed

By submitting a bug report you get in touch with the KDE bugsquad and developers. Make sure you will be around to give feedback and you should also be available for testing if needed. If you are not willing to contribute in that way, please do not submit reports as it will be causing more work for other people to test.

7. Be patient and polite

It is not always possible for the bugsquad and/or the developers to get back to you immediately. We get an average of 50 to 100 reports a day, of which most will be either duplicates or invalid, so there is quite some stuff to get through in a day.

Don’t forget that this is Free Software and almost all KDE people work on their projects as volunteers in their free time. So shouting at people working as volunteers is totally counterproductive as they will probably prefer to do something else instead.
Make sure you stay on topic and be polite and helpful in the same manner as you would expect others to behave towards you, this is more likely to make people work on solving the problem.
Another point to consider is that your use-case is not necessarily the unique one, there are often many ways to do things in an application and you know that KDE is highly configurable for the users. Don’t expect to be the one who does use an application in “the standard way” and be ready to accept a workaround.

If you want to help, you can of course also give a hand in triaging to clean up the database. We welcome all volunteers who want to contribute to make KDE even better! Feel free to come to the #kde-bugs channel on IRC and have a look at the links given below.

UPDATE: Just to put this in perspective of the work ahead I asked Ben Cooksley, one of our sysadmins, to give me some numbers:

With the sheer number of reports in KDE’s bugzilla and not enough people to triage, a valid report can well get drowned: as of today, October 20th 2011 the database has

• 278,805 total bugs
• 1,173,947 comments
• 64,469 attachments
• 234,403 are CLOSED/RESOLVED/VERIFIED
• 56,301 bugs were resolved as DUPLICATE
• 20,250 were resolved as INVALID.

• 40,571 open with the status ASSIGNED/ NEW/ REOPENED/ UNCONFIRMED
• 3,830 are in NEEDSINFO status
• 26,174 are UNCONFIRMED and need triaging

Thanks to Ben Cooksley, Martin Grässlin and Will Stephenson for suggestions and spotting typos

Useful links:

How to Report Bugs Effectively by Simon Tatham
Bug Writing Guidelines in Bugzilla
Quick Introduction to Bugzilla in KDE’s Techbase wiki
Guide to Bug Triaging by Dario Andrès in KDE Techbase

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.

As you may or may not know, the KDE git infrastructure currently has two assets for viewing repository data — Redmine and gitweb.

Redmine powers Projects at http://projects.kde.org and is intended (pending theming and greater population of data) to be the real “home” of all of KDE’s projects, putting project information, news, repository browsing and more in a pleasant UI. Each project with a git repository will have a project on Redmine as well as on ReviewBoard.

However, Redmine doesn’t have *all* of the git repositories available. This is because in the short term at least there won’t be projects created for user clones of repositories. In addition, the “scratch” area, where KDE developers can maintain their own repositories for anything they wish (that’s KDE-related of course) will never be put in Redmine.

(The reason for this is that if a developer just wants to play around with some code, or perhaps wants a location to store their (versioned) emacs/vi config files or some such thing, there’s no reason that needs to be an “official project” with an entry in Redmine and ReviewBoard. Similarly, if a developer is writing new code but feels that the code is far too raw to actually have others having eyes on it, we believe it should be up to them when they decide to have it put into a project on Redmine and ReviewBoard.)

So, let’s say you’ve just pushed some code. Where would you go to see it on the Web — Redmine or gitweb? I took a first cut at solving this problem by, based on the location of the repository you pushed to, spitting out a Redmine- or gitweb-based URL in the output sent back to your git client. Unfortunately, these were quite long. For example:

http://projects.kde.org/projects/repo-management/repository/revisions/dcd43aacaa806a7a32779a0215b7ab8ed7b05dc8

This isn’t so nice. Especially if your terminal is only 80 characters wide.

So, I came up with a solution — commits.kde.org. It’s a simple Sinatra/Thin-based web application that parses a URL generated by the gitolite hook and forwards you to the correct place. If the repository is on Redmine, it forwards you there; otherwise it forwards you to gitweb.

These aren’t tiny URLs in the style of bit.ly, but they’re deterministic and not based on a database backend. In fact, you can construct these on your own and they’ll still resolve. The form is

http://commits.kde.org/<repoid>/<commitid>

The repoid can be found by looking in the URL that is spit out when you push your code. It stays fixed for each repository (and if it does change, aliases can be added to keep old URLs alive).

In this format, the above URL goes down to

http://commits.kde.org/99c5fdd6/dcd43aacaa806a7a32779a0215b7ab8ed7b05dc8

By doing this, the URL size drops from 110 characters-ish (depending on the name of the project, whether it’s on gitweb or Redmine, and so on) to a fixed 72; enough to make it fit on a single line in most terminals (with the “remote: ” prepended to the git output it’s 80 characters total), and to make it relatively tweet-/dent-able if you don’t need to include much other information in the post.

Update: I should mention that you can shorten those URLs further, but how much depends on when you start getting a collision. If gitweb encounters an ambiguous commit ID, it will 404, without giving information as to why it returned a 404. Redmine, however, will simply return one or the other of the commits — so you may get the wrong commit shown without even realizing it. Worse, this could also mean that URLs that were shorter (very short) but once worked may not work later if a collision comes up later. So you can use as many or few of the hash characters as you want, but I’d stick with at least 8 or so for safety. *Also*, right now the webapp only matches full hash values in Redmine’s database, so if you shorten it you will always get a gitweb URL.

For anyone interested, the current webapp code is GPLv2+ and can be found right here.

Following recent tradition, here is another post mostly unrelated to Amarok (next one will be on topic, I promise)

The company that I have recently co-founded, Memolane.com is in need of a graphical and interactive lead designer.

So what do we offer?

As a very young startup, we offer long hours, constantly changing tasks (we all need to pitch in wherever needed) and huge responsibility for doing the best you can as there is no one else to fall back on.

But for the right person we also offer a unique opportunity to help shape a new company from a very early stage, to become a key part of a small, young and dynamic team, a very decent (for a young startup) salary and a nice little bag of lottery tic... uhm... stock options

If this person is you, get in touch with some examples of your previous work. If it is not you, but you know someone who might be interested, a good bottle of champagne or two is up for grabs for the person who refers us the designer we end up hiring.

Anyone interested or who wants to know more can mail me a "Nikolaj{at}memolane.com" or leave a comment below.

So, recently I was looking for something to do, but now I am in the position of having to turn down interesting offers because I am already committed elsewhere.

One of the projects I have been in touch with is of particular interest to me, as even though it is for a commercial company, the project that they need someone to work on would very much benefit the Free/Open Source software community in general and Amarok in particular, and therefore I offered to blog about it in the hopes that someone else might be interested in working with them. Had I not just a week before more or less accidentally co founded a startup (much more on that later), I would have been all over this project myself!

Basically they need a way to synchronize iPods on Windows and OS X, and rather than going a commercial route, they want to look into using libgpod and friends. Libgpod however is currently not ready for this task, as various bits are missing or needs to be improved on Windows and OS X, so the job is basically to do whatever is needed to fill in these missing bits.

They are looking for someone who can work full time on this and are willing to pay good money for it

If this sounds interesting, leave a reply here (remember to put your email in the comment form so I can get back in touch with you)