[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ A ] [ next ]

Custom Debian Distributions
Chapter 7 - How to start a Custom Debian Distribution


This chapter more or less covers the text of the Debian Subproject HOWTO which was written by Ben Armstrong synrg@debian.org. Ben has agreed that his text should be included here and the subproject-howto will be orphaned once the current document is ready for packaging.


7.1 Planning to form a Custom Debian Distribution

In this section issues to think about before starting a Custom Debian Distribution will be discussed. It is important to have a clear idea where to head and how to get there before launching into this adventure.


7.1.1 Leadership

The currently existing Custom Debian Distributions showed clearly that they depend from a person who keeps things running. If anybody wants to start a project at first he has to answer the question: "Am I the right person for the job?" Surely this is a question which leaves a certain amount of uncertainty. The way the currently existing Custom Debian Distributions started in the past was that somebody had the idea that something has to be done and started doing it. After some time it became clearly visible that without a person who is taking over the leadership the project stays stale. So the initiator has to answer the question clearly, whether he is able to take over this job regarding the time he has to spend and the technical and social skills which are needed.


7.1.2 Defining the subproject scope

It is as important to decide what your group is not going to do as it is what it is going to do. A clear border line is essential for the development of the project and also for outsiders who might either expect more from the project as it can do or sometimes ignore the project because they do not regard it as helpful because they are not able to find out the purpose.

By maintaining a good relationship to other Free Software projects some common tasks can be done very effectively. Thus efforts can be shared and looking for allies could reduce the amount of work to do.

Checking for cooperation with other Custom Debian Distributions is always a good idea. In technical terms this is obvious but sometimes there are possibilities to share efforts by goals that have parts in common.

Who decided to start a Custom Debian Distribution takes over a responsibility for this project. It has to be for the good of Debian as a whole and should bring an extra reputation to our common goal to build the best operating system.


7.1.3 Initial discussion

By the time you have begun to think about forming the subproject, have made the commitment to lead it, and have sketched out a bit of where you want to go and how you'll get there, you have likely already done some informal discussion with your peers. It is time, if you haven't already, to take these ideas to the broader Debian developer community, opening discussion on the creation of your group.


7.1.3.1 Calling all developers

At this stage, you will want to reach as broad an audience as possible. You have carefully thought out what you're going to do, and are able to articulate it to Debian as a whole. Let everyone know through the debian-devel-announce@lists.debian.org mailing list, setting the Reply-to:debian-devel@lists.debian.org and listen to what everyone has to say about your idea. You may learn some valuable things about pitfalls that may lie ahead for your group. Maybe even show-stoppers at that. You may also find a number of like-minded individuals who are willing to join your group and help get it established.


7.1.3.2 Steering the discussion

It's all too easy to get lost in ever-branching-out sub-threads at this point. Many people will be firing off ideas left, right and centre about what your group should do. Don't worry too much about containing the discussion and keeping it on track with your main idea. You would rather not squelch enthusiasm at this point. But do try to steer the discussion a bit, focusing on the ideas that are central to your subproject and not getting lost in the details.

At some point, you'll decide you've heard enough, and you're ready to get down to the business of starting your group.


7.2 Setting up


7.2.1 Mailing list

It is fairly important to enable some means for communication for the project. The most natural way to do this is with a mailing list.

Creating a new mailing list starts with a wishlist bug against lists.debian.org. The format of this bug has to follow certain rules.

Before your list can be created, the listmasters will want assurance that creation of the list is, in fact, necessary. So for this reason, don't wait for your list to be created. Start discussing your new project on debian-devel@lists.debian.org immediately. To help distinguish your project's posts from the large amount of traffic on this list, tag them in the Subject field with an agreed-upon tag. For instance for general discussion about Custom Debian Distributions the tag [custom] should be used. An example bug report to create the relevant list is bug #237017.

When sufficient discussion on the developer's list has taken place and it is time to move it to a subproject list, add to your wishlist bug report some URLs pointing to these discussions in the archives as justification for creation of your list.


7.2.2 Web space

A fairly important way to give people an idea as to what your Custom Debian Distribution is about is certainly a web page. While there are a number of ways to go about this, the simplest is to put them at the developer home page at people.debian.org in case an official Debian developer is starting the project.

Another possibility, and one which is fairly attractive because it facilitates collaborative web site creation and maintenance, is to put a page on the Wiki. There is a special Wiki page for Custom Debian Distributions.

Finally, the best way is to have a page under www.debian.org/devel. While not as straightforward as maintaining a personal page or a Wiki site, this approach has its advantages. First, the site is mirrored everywhere. Second, the Debian web site translators translate pages into many different languages, reaching new potential audiences for your Custom Debian Distribution and improving communication with other members of your project and interested parties for whom English is not their most comfortable language. Third, a number of templates are available to make your site more integrated with the main web site, and to assist with incorporating some dynamic content into your site.

Once this is done the Debian web pages team should be contacted via the mailing list debian-www@lists.debian.org to add the project to the organisation page.


7.2.3 Repository

On alioth.debian.org a Gforge-site is running to host all Debian related project work. Creating a project on Alioth is a good idea to start teamwork on the code a certain Custom Debian Distribution is releasing.


7.2.4 Formal announcement

Once there is a list, or at least some preliminary discussion on debian-devel to determine, and there is some information about the newly to create Custom Debian Distribution available on the web which can be linked it is time to send a formal announcement to debian-devel-announce@lists.debian.org. The announcement should include references to past discussions, any web pages and code which might already exist, and summarise in a well-thought out manner what the project is setting out to achieve. Enlist the help of fellow developers on irc or in private email to look over the draft and work out the final wording before it is send out is always a good idea.

Mails to debian-devel-announce@lists.debian.org have to be signed by the GPG key of an official Debian developer but it should not be a very hard task if somebody wants to support Debian while not yet being a developer to find a developer who volunteers to sign an announcement of a reasonable project. It might be reasonable to send this announcement also to non-Debian lists as well if they cover the same topic as the Custom Debian Distribution. If your announcement is well done it will generate a huge amount of answers from many outsiders and is able to attract people to Debian.


7.2.5 Explaining the project

Now the real work starts. People who are involved into the project should be aware that the have to answer questions about the project whenever they show up at conferences or at an exhibition booth. So being prepared with some flyers or posters is always a good idea.


7.3 Project structure


7.3.1 Sub-setting Debian

While there are a variety of different kinds of work to be done in Debian, and not all of them follow this pattern, this document describes one particular kind of project. Our discussion about Custom Debian Distributions concerns sub-setting Debian. A sub-setting project aims to identify, expand, integrate, enhance, and maintain a collection of packages suitable for a particular purpose by a particular kind of user.

Now, strictly speaking, a subset of packages could be more general than described above. A subset could be a broad category like "audio applications" or "network applications". Or it could be more specific, such as "web browsers" or "text editors". But what a sub-setting project such as Debian Jr. aims to do is not focus on the kind of package, but rather the kind of user. In the case of Debian Jr. it is a young child.

The sort of user the project looks after, and which of the needs the project hopes to address are, defined by the projects goals. Thus, Debian Jr. first had to decide which children: What age? English speaking children only, or other languages as well? And then the project had to determine how and where they would be using Debian: At home? In school? Playing games? On their own systems? On their parents' systems?

The answers to all of these questions are not straightforward. It is very much up to the project to choose some arbitrary limits for the scope of their work. Choose too broad a focus, or one which duplicates work already done elsewhere, and the energy of the project dissipates, making the project ineffective. Choose too narrow a focus and the project ends up being marginal, lacking the critical mass necessary to sustain itself.

A good example was the request to split the part of microbiology related packages out of Debian-Med into a Debian-Bio project. This is reasonable in principle and should be really done in fact the initiator of Debian-Med would support this idea. So he gave the answer: "Just start the Debian-Bio project and take over all related stuff. Until this happened we will serve medical stuff which has to deal with sequence analysis etc. with Debian-Med services." Unfortunately there was silence around Debian-Bio after this answer ...

Of course, it sometimes turns out that you start working on a project, thinking you know what it is about, only to find out later that you really had no idea what it would become until the user base has grown beyond the small community of developers that started it. So none of the decisions you make about your project's scope at the beginning should be taken as set in stone. On the other hand, it is your project, and if you see it veering off in directions that are contrary to your vision for it, by all means steer it back on course.


7.3.2 Using tasksel and meta packages

According to the plan of the project the first meta packages (Meta packages, Section 6.1) should be developed. It is not always easy to decide what should be included and which meta packages should be built. The best way to decide here is discussion on the mailing list some well though proposals.

Section Text user interfaces, Section 6.2.2 mentions tasksel as a tool to select a Custom Debian Distributions and explains the problem why it is currently not possible to get a Custom Debian Distribution included into the task selection list.


7.4 First release


7.4.1 Release announcement

Beyond the release announcement for Debian itself, it is necessary to put some thought and work into a release announcement for the first release of a Custom Debian Distribution. This will not only be directed at the Debian developer community but also to the users. This will include potential new Debian users abroad, who may not be on a Debian mailing list. Here applies the same as for the first announcement of the project: Propagating the information to relevant places is an important issue.


7.4.2 Users of a Custom Debian Distribution

By this time people have newly installed Debian along with the stuff of the Custom Debian Distribution, or have installed the meta packages on their existing Debian systems. Now comes the fun part, building relationships with the user community.


7.4.2.1 Devoting resources to the users

Users are mixed blessing. In the first development phase, there are some developers as users and some intrepid "early adopters", but once it is released, the first version is "out there" and the project is necessarily going to attract all kinds of users who are not necessarily as technically savvy as your small development user community. Be prepared to spend some time with them. Be patient with them. And be listening carefully for the underlying questions beneath the surface questions. As draining as it can be to deal with users, they are a very key component to keeping your development effort vital.


7.4.2.2 Developer vs. user mailing list

Should a user list be created? It's not as cut-and-dried as it might at first appear. When user help requests start coming in, you might at first see them as a distraction from the development effort. However, you don't necessarily want to "ghettoize" the user community into a separate list early. I think that's a recipe for developers to get out of touch very quickly with the users. Tolerate the new user questions on the developer list for a while. Once a user list is finally set up, courteously redirect user questions to the user list. Treat your users as the valuable resource about how your project is working "in the field" that they are.


7.4.2.3 User support beyond Debian

Fortunately, we're not in the business of supporting users alone. Look beyond Debian for your allies in user support: Linux user groups (LUGs), the users themselves. Develop an awareness of who has stakes in seeing your project succeed, and enlist their help in getting a strong network of support established for your work.


[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ A ] [ next ]

Custom Debian Distributions

28 July 2004

Andreas Tille tille@debian.org