Project Timelord -- The Timeline
echidnaman at gmail.com
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 kdenews.org. This will
be an important part of restoring our image, so we should make a big deal
- 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.
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
1. Review all patches
(http://docs.google.com/View?id=dfc7xjfj_18g8k5ztg4#Packaging_flaws , 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 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
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
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