About me

I am 23 years old and I come from Latvia. By the election time I will have just finished my Masters degree in Cranfield University, UK. While I have been a Debian Developer since 2000, my involvement in Debian has been quite low and was more of the social side. Anyone who has ever looked at my code, will tell you that I am a lousy coder. My stronger side is higher level architecture and translation between the language of coders and that of managers and politicians. Most of my time has been spent on other free software related activities such as founding and running the Latvian Free Software Association and lobbying against software patents in EU. I have also participated in Google SoC, once as a student and once as a mentor.

Goals

My goal of running for DPL is not to be DPL, but to get a few concepts closer to real life. Concepts that, in my mind, would make Debian better and even more important for the future world than it is now.

Release

First of all, I want to get the basic question off my back -- if I were elected DPL, I would like to not have a Debian release during my term (except etch). My opinion is that Debian should release at a rate of once per two years. Only with that timeframe I can see there being enough time for a good stretch of unstable development and a healthy freeze timeline. Additionally that would allow some time for first stage implementations for the next two ideas.

Distribution trunk

Pre-idea

There are 150+ Debian-derived distributions in the wild. One of them (Ubuntu) has gathered more mindshare than Debian currently has, with a fraction of resources. It has even been suggested that what Ubuntu is doing is downgrading Debian from a distribution experience to a kind of supermarket of raw ingredients from which Debian-derived distributions (such as Ubuntu) take raw packages and then prepare them in some way to present them to their users. It has been feared that with such growth Ubuntu could attract more new users and (crucially) new developers than Debian and with time leave Debian behind.

The idea

What if there was on common base that all Debian-derived distributions could use equally, like a trunk of a distributed source control system? What if "Debian release" and Ubuntu would be equally important but different branches of such distributed source control system (just like all other 150+ Debian-derived distributions)? What if anyone willing to create another Debian-derived distribution would be able to do that just by running a few commands and could equally choose and other Debian-derived distribution as his base? What if he would be able to do so wither on his private server or on Debian servers (if he has the permissions)? What if Debian-derived distributions (including "Debian release") could be easily forked or merged? I am sure that everyone can imagine at least a few benefits and opportunities provided by such changes.

Post-idea

Such a change would require close cooperation between core developers of Ubuntu and Debian. Significant changes to our tools, procedures and mindsets would be required. Many new tools may have to be written (if Linux kernel people can write git, why cann't we write a distributed, branch capable BTS?). Many problems will be solved or become easier to solve if/while such distribution trunk is created:

However, even if I get elected DPL, I assume that a year or two will be spent just planning out the changes and new developments required to make something like this really work.

Configuration file and home folder reform

A less controversial and less ambitious project that I want to push forward is the configuration file and hoe folder reform. I have blogged about it before. However there are few things that did not make it into those blog posts. In short the idea is to make several consecutive changes:

  1. Move all application file in users home folder into a structured form: ${HOME}/.apps/${APPNAME}/[config,cache,data,plugins]. This will remove the clutter of dot-files in users home folder and will provide a way to: 1) remove all configuration information of an application by name, 2) exclude all temporary cache information of all applications from backups or remove it when disk space is low
  2. Define standard configuration formats. Create libraries and tools that ease handling of these formats from applications, including verification tools. Allow the configuration file format to be easily changed by the administrator. Allow creation of interfaces that would be able to configure any application with a standard configuration file format. Convert all application to use of these configuration file formats, preferably using standard configuration file access libraries.
  3. Extend the format of ${HOME}/.apps/${APPNAME} folders to allow share, lib and bin subfolders containing whole applications. Make it possible for such folder to be copied across computers for the purpose of third-party software installation by users in a way similar to Mac OS X. An application could be distributed as a zipped folder (with a custom file extension) which can be either run directly by double-clicking it in a GUI or installed to ${HOME}/.apps/ with a couple of clicks and uninstalled by simply deleting the folder. Hooks into menu and the GUI updating software would allow such application to show up in the menu and be (securely) updated.

Even implementing the first part only would take more than one year in the Debian context, but on the other hand Debian is in an unique position of actually having the ability to make such changes happen (just like FHS compliance).

Old Maintainer Process

Some Debian Developers who have been around for many years would be hard pressed to pass the New Maintainers process as it is now. It is only natural - demands get higher, new processes and technologies appear. However I do no think it is fair to subject new Debian Developers candidates to tests that some of us might not pass. What I suggest is to instate a procedure of regular reevaluation of Debian Developer skills outside their regular packages. It should not be much harder than the NM process is currently and should not be too frequent (say, every 5 years), but the key of the process is keeping open the flow of knowledge and best practises within the project. In addition this will allow to detect developer that have gone MIA or just have not read the Debian Policy since getting trough the NM. Think of it less like an examination and more like a old pal checking up on your health.

No more trademarks

I have talked about this before - we should just make a GR and decide to drop all our trademarks and ask all other free software projects do the same.

Why choose me

Choose me, if you want to stop talking about petty issues and start thinking big again. Debian is the largest single force in free software. We should act like it and show some leadership.

Summary