Xfce 4010 – (release-schedule and versioning)
Hi all,
There has been a lengthy discussion about the xfce version-number.
Is it OK to call the next version of xfce 4.10?
Some package maintainers have a problem with 4.10 being a later version then 4.8, since they see 4.10 as 4.1 with an extra decimal for precision.
Since it could cause upgrade-problems for several distributions, we should find a way to solve that problem.
Why not go for 5.0?
If the ‘.’ is a decimal-separator, a 0.2 upgrade from 4.8 would end up at Xfce 5.0. But we already discussed that . We are not going for 5.0, it would only create confusion, and people start thinking we pulled a ‘gnome-3’ on them. So that one was out pretty quick.
But, the confusion remains. Olivier Fourdan argued that we could think of it as a hexadecimal value, so 0x4.8 would be followed by 0x4.A. Though this sounds funny, and it solves our problem for a few versions (0x4.C, 0x4.E) but we’d end up with 0x5.0 eventually… resulting in the same problem.
And nobody uses the hexadecimal system for version-numbers, that is silly.
So? Now what?
It took a while before we realized, that the ‘.’ could be seen as a separator for thousands (it’s used like this in most of Europe). So you’d have Xfce 4,008 and Xfce 4,010. This not only solves our problem for the next version. At the rate of one release every 2 years we stay away from the whole 5.0 discussion for another 990 years. (Unless another reason appears to introduce a 41xx series of 50xx series of Xfce somewhere this century).
So, here’s the conclusion:
The next version of Xfce will be Xfce 4010 (four-thousand-and-ten)!
But that’s ridiculous!?
Well, it used to be. But these days anything is possible with version-numbers really, except for going backwards.
Which is precisely what we are avoiding here.
Just look at Mozilla Firefox (moving from 4 to 9 at the same pace as they went from 0.7 to 1.0) or Google chrome (what version-number are they using anyway?), or the linux-kernel, going from 2.6.0 to 2.6.39 with entire subsystems being rewritten from scratch, and then moving from 2.6.39 to 3.0 without any radical change whatsoever.
Really, moving from 4.8 to 4010 is not really that big a deal, if it serves the right purpose.
That’s nice and all, but when will we get it?
Ah, more good good news :)
We have a new schedule. (it is not published to the wiki yet though)
Essentially, the development-phase is pro-longed until the weekend after FOSDEM, giving us time to do some hacking there and get it in master the week after.
| Dates | Phase/Deadline | Everyone’s Tasks | Release Team Tasks | Maintainer Tasks |
| 2011-Feb-13 – 2012-Feb-12 | Development Phase | Support Xfce | Supervise development, remind people of deadlines | Hacking |
| 2012-Feb-12 – 2012-April-01 | Release Phase | Wait patiently | Perform releases, remind people of deadlines | Perform releases of own components if desired |
| Xfce 4010pre1 (Feature Freeze) | Prepare release announcements, release Xfce 4010pre1 | Make sure the latest development release is in good shape and uploaded | ||
2012-March-11 |
Xfce 4010pre2 (String Freeze) | Prepare release announcements, release Xfce 4010pre2 | Make sure that strings in the latest development release or in master are good | |
2012-March-25 |
Xfce 4010pre3 (Code Freeze) | Prepare release announcements, release Xfce 4010pre3, create ELS branches | Make sure the latest development release is in good shape, or that code is solid/finished in master | |
2012-April-01 |
Xfce 4010 (Final Release) | Celebrate | Prepare release announcements, release Xfce 4010, branch for stable release, merge ELS branches into master | Make sure to upload a new release of own components before this deadline |
We hope you are as happy as we are with the new release schedule.
Update: There was some confusion about the date notation, updated it to get rid of the month-numbers.
Update-2 [18-01-2012 13:37 CET]: For more background information about this decision, check this link
Documentation Wiki
Over the last years we’ve tried many techniques to make it easier to submit documentation for the Xfce packages. Unfortunately, whatever we’ve tried; hardly any documentation was contributed.
Complete documentation (or close to that) was still a goal for Xfce 4.10, so we’ve decided to drop the package manuals for the next stable release (now GIT master) and focus on a wiki-based setup. This means that the Help buttons in 4.10 will try to open your web browser and redirect you to the correct page on docs.xfce.org.
We understand a small group of people without Internet are affected by this change. However as the situation is right now, clicking the Help button is often not even possible and once the wiki is starting to grow, we’ll look into an xfce4-docs package that contains a snapshot of the wiki data.
We hope with this change the barrier to contribute manuals is low enough for contributors to help us with good documentation, so Xfce 4.10 will be the best documented release we’ve ever made (and that should fairly easy ;-).
Xfce git modules
I needed to update my scripts to checkout everything in the Xfce git repositories. I used to run something like ssh ls /var/git on mocha (our old git server) to get the list of modules, but now I have this:
lynx -dump -listonly git.xfce.org \
| grep "git.xfce.org/[^?]" | grep -v "archive" \
| sed -e 's^.*http://git.xfce.org/^^' -e 's^/$^^'
Any better suggestions? This works very well for me, already.
Now, unfortunately, I have not found the time and energy to do something useful with all that fresh code. But it feels good to know it’s there if I do ;-)
Looking for new maintainers for some of my projects
I am looking for a new maintainer for some of the open source projects I started over the last couple of years. Due to taking a full-time position as a software engineer, I will have less spare time to hack in the near future than I had while being a student. I will continue contributing to Xfce but I would like to focus on core development (thunar, tumbler, garcon etc.). As a consequence, I am looking for people interested in maintaining the following projects:
- thunar-media-tags-plugin
- xfce4-verve-plugin
- xfce4-mixer
- xfce4-time-out-plugin
- jptemplate (see http://lunar-linux.org/~jannis/jptemplate/ for documentation)
Most of these are smaller projects but some of them (like thunar-media-tags-plugin and xfce4-mixer) have many users. xfce4-mixer is particularly interesting, I think. It’s code base is of medium size and it lacks integration with notification daemons, key bindings for muting and altering the volume of a selected channel. Also, the per-channel widgets could be arranged in better ways than they are right now. PulseAudio support has been requested several times but that is an entirely different story. xfce4-mixer is mainly intended as a mixer for GStreamer. A PulseAudio mixer would better be written from scratch. But if anyone is up for the task - why not!
If you are interested in maintaining any of the above (yes, you are free to rename jptemplate to something that does not carry my initials!), please let me know in a comment or send a mail to xfce4-dev@xfce.org!
(You will need knowledge of C, GLib and GTK+ for the Xfce projects and VIM script for jptemplate. But in particular panel plugins are really simple, so the code base should be easy to understand even for a GTK+ newbie who is willing to read API manuals.)
Joining Codethink
I already hinted at the end of my studies in earlier posts related to my thesis. After submitting that thesis I moved 400km south of Lübeck to enjoy a few quiet weeks, record music and work on Xfce. However, I only stayed there for two weeks before I was set to fly over to Manchester, UK. The reason: I will be joining Codethink in January!
Having spent the last three weeks in and around their office, the city of Manchester and one of its suburbs, I can confidently say that this was a great decision. Codethink is a social and diverse company with a strong background in open source, with bright people, and a nice overall atmosphere and attitude. We had plenty of enjoyable evenings, chats, not to forget the brilliant food. I managed to feel at home already, but sadly, I had to leave again yesterday.
Like many people in Codethink, Manchester appears to be a city that likes music, a place where almost everyone is either a die-hard music fan or even a musician. I found a room right in the hart of the northern quarter at 10 minutes walking distance to the office, surrounded by record shops, live music venues and pubs. Rehearsal spaces are expensive but nearby. I could list various additional reasons for why I’m really happy. This simply is a good move.
About three years ago I was about to cancel my studies and look for a job. In the end I decided to carry on. Last week my Diplom (the German equivalent of an MSc) certificate arrived. Despite many doubts throughout these years, I managed to graduate with honors. It’s funny that this grade will have no impact on anything and is only really useful for proving to myself that I can pull through if I really want to. But then again, I had a great and chilled time being a student. So in retrospective, I guess I only ever had doubts because I was impatient and eager to make a difference in what was supposed to be the “real world”.
Now, with Codethink, I can.
Learning from GNOME
I just read an interview with Federico Mena-Quintero, which is a good read in its entirety, but one thing struck me as being a very important change to how GNOME is being developed.
Federico says (emphasis mine): “The latest thing is that now things have to go through the design team first, and I don’t think that is a good thing; there should not be a central body of control that decides how things are done, because that simply doesn’t scale. And it also doesn’t teach people in how to do design properly. I really would like to move to a model where, instead of having a central body of people who can veto things in or out, we can have a shared understanding of what constitutes good design and implementation.”
This has been very important in my personal development as a programmer. I remember the vivid discussions about usability on the gnome lists with well-known names like Havoc Pennington. And they helped me enormously to form my own opinions on these matters.
From a (safe ;-) distance it seems like GNOME is missing a big opportunity to teach the world, oh alright, other free software developers about good design and thereby giving chances to new developers to learn from their peers. Specifically, it is not as easy as it once was for a casual observer to gain an understanding of the concepts and their implementation that are the basis for gnome development and that’s a real pity, I believe.
Ristretto 0.1.x — Getting rid of anoyances…
Over the past few years, the top 2 complaints about ristretto have been ‘it leaks memory!‘ and ‘it crashes in this <obscure> way when I press this button‘.
And you know… these people were right. During the past 6 months, my main focus was fixing these problems. After a lot of code-simplification and refactoring, I finally managed to fix all the reported crashes and memory-leaks. (Yes, I know this took a while…)
In my opinion, this made ristretto 0.1.0 the most stable release so far.
But there are still quite some improvements to be made by removing nuisances in the user-experience. Some of these have already been addressed in 0.1.0, including:
- Support for using arrow-keys to navigate through the images
- Additional accelerator for the ‘f’ key for switching to full-screen-mode
- Additional accelerator for the ‘q’ key for quitting ristretto
- Modify scroll-zoom so the mouse-cursor stays above the same region of the image when zooming in or out
- Re-introduce the file-properties dialog.
There are still some things that can be improved with regards to usability, I will work closely with the Xfce Design SIG to identify and improve problems with the ristretto UI. One of the things I will finally start on improving is the sorting-algorithm used for sorting the images on their filenames (Bug #6866), so the images are sorted in a similar order as they are in Thunar.
The main focus during the 0.1.x release-cycles is getting existing functionality to work better, so expect a faster release-schedule featuring smaller changes for the coming months.
On MeeGo
Whatever MeeGo was, it never made it into the open source mainstream, which I consider to consist of projects actively worked on by volunteers and companies alike, and didn’t manage to become an project attractive enough for individual open source enthusiasts not driven by money to make substantial contributions.
There is enough room to speculate over the reasons why this is. My personal take is that MeeGo failed to be a successful open source project because the corporate commitment to the open source idea was not strong enough and expectations were too high right from the start.
Open source projects start with an idea and evolve into a proper product over time. Sometimes they are developed incrementally, sometimes it happens that big parts of them are replaced all at once. The idea behind an open source project may be huge but they all start off with baby steps. MeeGo, however, wasn’t supposed to. The idea behind MeeGo was big, and due to market pressure it was expected to become complete and successful quickly. It occurs to me that the idea was to sort of guarantee success by providing the project with professional, corporate governance.
I think everyone who started working on open source as a hobby knows that this is something a lot of hackers don’t are comfortable with. An open source project under corporate leadership may easily suffer from top-down decisions that give developers the feeling of working in a restrictive environment rather than a playful one. I’m not surprised by the fact that the only people I know ever contributed to MeeGo worked either for/with Intel or Nokia.
It isn’t the technologies, tools or frameworks that are reason for the failure of MeeGo. KDE and GNOME are large and successful projects based on Qt, GTK+, Clutter, D-Bus-based desktop middleware etc. What has lead to failure in my eyes—-the eyes of an outsider, opn source developer and potential user—-is that the dynamic nature of open source projects conflicted with corporate expectations and hopes for a quick success they needed so badly. Add to that the pressure on Nokia, the corporate culture clash of two global information technology companies and the fast pacing world of mobile devices and interfaces, and you have a pretty explosive mixture.
Personally, I won’t place my bets on Tizen. I can only imagine how frustrated and disappointed everyone who tried to get involved may be today, even those who contributed to MeeGo as part of their work for Intel, Nokia or one of the many smaller companies that make up the corporate part of the open source ecosystem. It is also frustrating for me as a developer aiming for a job in open source and desktop/mobile/UI technologies.
I guess the mobile open source platform we are all hoping for will be there some day. But it will only appear slowly, driven by the efforts of enthusiastic individuals with big ideas, realistic expectations and sound knowledge of the pace and dynamics with which open source projects grow and mature. This of course relies on open hardware and I don’t know enough about the manufacturing industry to predict the availability of open, hackable devices in the near future.
In the meantime, the best we can do as open source software developers is improve the base OS level and innovate in desktop/mobile/UI technologies by experimenting with new ideas and extending existing frameworks. I’ll help where I can.
Hiding backup files in Thunar
There was one feature in the new Thunar with GIO (since Xubuntu 11.04 Natty) that I didn’t like. It was stubbornly showing backup files (*~). I asked the Thunar developer Jannis Pohlmann today if there is a solution/workaround for that, and there definitely is!
Close Thunar, add the line MiscShowBackup=FALSE at the end of your ~/.config/Thunar/thunarrc and launch Thunar again and you’re not seeing the backup files anymore. What a relief. Thanks Jannis!
On a sidenote, I’ve finally started making decent, serious backups of my (Open Source) work. The rsync-based script works better than I could have ever imagined. Thanks go to Marko for that.
Looking for a full time job in Open Source
Two years ago I was really close to canceling my studies and looking for a job instead. In the end I continued studying, passed the final exams of my Diplom (the German old-school equivalent to a Master’s degree) with excellent results and started working on my graduate thesis. Today, I am 1 1/2 months away from the submission deadline and it is clear that I will make it.
So, this time I’m serious: I’m looking for a full time employment in Open Source software development, engineering or management starting November this year. Hiring me will get you an experienced and talented hacker with a natural intuition for software architecture and aesthetics as well as a scientific and painstaking approach to software planning and implementation.
Through my work at the university and within the Xfce and Lunar Linux projects, I have gained experience in/with
- many programming languages (including C, C++, Ruby, Python, Vala, Lua, XSLT, TeX, Java, Bash and a couple of others),
- many frameworks (the whole GTK+/GLib stack including D-Bus, a bit of Clutter, XLib and Qt/QML, SWT/JFace, the FOX toolkit as well as web frameworks like Sinatra and Rails; some knowledge about the Linux kernel, its facilities and kernel-userspace communication mechanisms included),
- many developer tools (GNU compilers, Autotools, VIM, NetBeans, Eclipse and others),
- many software versioning systems (Git, Subversion, CVS and Mercurial), and
- various areas of computer science and software engineering (complexity theory, signal processing, graph drawing, micro-controller programming and sensor-based networking, software planning, testing etc.).
I feel equally at home developing for the desktop or for the web. Granted, my main area of expertise is user interface and middleware development on Linux, which my fellow Xfce hackers and I have successfully participated in, but I’ve always found web development with Ruby to be a refreshing change.
There are many other things related to open source that I love doing. Over the past years I’ve enjoyed being able to improve the transparency of the development and release management of Xfce. Streamlining the release process and providing tools for making release management fun was an initiative I am particularly proud of. The same goes for community efforts like the Xfce Foundation, which we’ve launched in early 2011 and which I am currently heading as president.
This post is not just about the past though, it’s also about what lies ahead. Things I am particularly interested in with regards to the future include
- mobile platforms and applications (iOS and Android are not good enough, I think we need open alternatives),
- multi-touch interfaces on Linux (yep, this is on the way, but there still is a lot of potential work to be done, I guess),
- cloud-based applications (I know I can store files and data on the web, but where are the mind-blowing features that go beyond availability of personal data everywhere?), and
- environmental and power saving applications (living responsibly will become important soon enough; how can we generate awareness and support environmental causes with the help of software?).
I am excited and curious what my role will be in all this. Anway, I guess this is enough information about me for now. After all, this is no biography but a job-search post. ;)
If you read this and you happen to be Microsoft or Apple, do not even bother to send a headhunter. I prefer to work in the open and I believe in Open Source for many reasons. This ecosystem that we’ve created over the past two decades provides a great way for people from all around the world to collaborate on projects they care about, in an honest and tolerant way. I think that’s an inspirational model from which our entire society can and hopefully will benefit. Why would we want to have it any other way?
If you are a member or leader of a company dedicated to Open Source software and are interested in hiring me, please let me know. Linked below are my resumé, software projects and email address. I’m looking forward to talking to you!
Download my resumé/CV — A list of references is included. Feel free to contact them; they are aware of being listed and I’m sure they will be happy to answer any of your questions.
My software projects — A list of open source software projects I am or have been working on.
Email address: jannis@xfce.org