Project Timelord -- The Timeline

Jonathan Thomas echidnaman at
Fri Oct 23 01:29:27 BST 2009

Alas, we do not have TARDISes, so we can't visit the future to see how things 
are going. But what we can do is lay out a sensible plan to give a certain 
amount of guidance and purpose towards our work, and since it looks like 
everybody seems to like the general idea of Project Timelord, we can move 
forward a little bit. Please feel free to discuss anything about the current 
plans, since this is very much a community decision even if a handful of 
developers chose a fancy name to put on it. :)

The following is what Project Timelord has envisioned as both a short and long 
term roadmap to success (tm)

Pre/early 10.04, lay foundations:
1. Announce Project Timelord to the world! his will include:
  - Blogging everywhere, perhaps do an announcement on This will
    be an important part of restoring our image, so we should make a big deal
    of it.
  - Establish a Timelord <-> upstream communication link. Ask what upstream
    expects Kubuntu to do and be(come), where they think Kubuntu provides a
    inferior KDE implementation and what they like about Kubuntu. In general
    get an idea what upstream thinks.
  - Work with upstream to work upon improving, based on upstream feedback.
2. Establish intrinsic policy changes:
  - Establish new bug triage policy. As it currently stands in discussion,
    this would mean directing more stuff to upstream
  - Make it a practice to always consult with upstream personally to determine
    whether or not a currently-pre-release piece of software will be ready for
    our release. To assume makes an ass out of u and me. ;-)
  - Re-evaluate support policies. We should look to see what level of support
    we can really provide for our "officially" supported releases. At the
    moment we really can't provide total support for 4 releases all at once.
    For example the non-security SRU rate for Intrepid is abysmal, with Jaunty
    only gaining fixes for the most critical of issues it was released with.
    Once we come up with something concrete, we should write it down.

Ongoing changes:
1. Improve marketing, promotion.
2. Improve developer-user interaction.

This is where we start to get in to actually doing stuff for releases. 
Coincidentally, it's also where the bulk of the work lies. Project Timelord 
does have a list of things it would like to see in 10.04, aside from the mass 
of "in a perfect world" improvements that could be made later. So, without 
further ado:

1. Review all patches 
( , third 
2. Fix translations, through whatever means necessary 
3. Improve quality assurance 
4. Re-evaluate ALL current default applications for ALL purposes, keeping in 
mind: size, functionality and localization. Make changes as necessary.
5. Do thorough testing of all current Kubuntu-specific applications, making a 
list of all bugs encountered and quashing as many as possible. (It's an LTS 
after all, and some of our apps have embarrasingly old bugs)

This is where we get into the broader job category of improving our software 
stack. It is obviously not prudent to try to do everything at once, so we must 
prioritize. Out of the solutions listed at 
, we should through discussion here prioritize them and plan a few for each 
release. Feel free to make your own personal proposed timeline and post it 
here. We'd love to hear it. :)

In my personal (non-Timelord) opinion here is a list of improvements to our 
applications ordered from most important to "maybe later".

- Complete gdebi/install-package depreciation. This should be a low-hanging
  fruit and would right off the bat mean two less applications for our limited
  resources to maintain.
- Drive the kubuntu-notification-helper project to be a suitable replacement
  for update-notifier-kde. This is also more of a low-hanging fruit since much
  of the initial work is done.
- Port printer-applet from KSystemTrayIcon to KNotificationItem. Should be
  really easy, and if nobody else steps up, I can do it.
- Package/Install kcm-touchpad[1] by default. This one isn't listed in the
  Timelord document, but Roderick Greening has filed a spec for integrating
  touchpad config into Kubuntu. Upstream has cooperated to provide support for
  the XInput backend, satisfying concerns about the future-proofness of SHM,
  so I think this would be an excellent solution.
- KAuth support for userconfig. This is important for integration as it's not
  nice to pop it up in a separate window, plus if we can git rid of all KCMs
  that need a separate window we can drop a patch in kdebase-workspace
- Integrate/rewrite language-selector-qt to make it fit in more with System
- Integrate software-properties-kde into System Settings. Will require a bit
  of help from Ubuntu to make software-properties PolicyKit ready.
- Port printer-applet to C++. Might be entering into pipe dream zone here...

So, continuing on the 10.04 timeline I started above:
6. Depreciate gdebi
7. Include kubuntu-notification-helper
8. Printer-applet KNotificationItem port
9. kcm-touchpad
10. KAuth in userconfig (deferrable if necessary)

All in all that should give us a fairly full plate for 10.04, and give all the 
UDS attendees plenty of stuff to flesh out. Though maybe we could do it all 
here and give the UDS peeps more time for hot tub parties, kareoke and 
snoring. :D

Continuing, my personal timeline for the future:

10.10 through 12.04, the next LTS:
- Language-selector revamp
- Software-properties-in-System Settings
- Port printer-applet to C++
- Jockey in System Settings
- Daft things we think sound good at the time. :P

Obviously planning out things a year and a half would make no sense, so I 
lumped all the rest of the ideas into a nice year and a half period. :) It 
would be nice to get most of them done by 12.04.

Anyways, Project Timelord would all like to hear what you think the Kubuntu 
timeline should look like, and I personally am curious what all of you think 
of mine. :)


More information about the kubuntu-devel mailing list