At: DebConf9
http://penta.debconf.org/dc9_schedule/events/463.en.html
https://debconf9.debconf.org/

DebConf9 introductory session

Welcome session

Welcome session

Room: Upper talkroom
Scheduled start: 2009-07-24 17:30:00

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/511.en.html
https://debconf9.debconf.org/

How to spend more of Debian's money

Debian has quite a large amount of money held in trust at SPI and elsewhere. Probably too ...

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/466.en.html
https://debconf9.debconf.org/

Bring DebConf home!

Every year, the location for DebConf, the annual international Debian conference, is selected via a competitive bid process. Although we haven't got to DebConf9 yet, organising a conference isn't quick, so it's already time to start thinking about a location for DebConf11.

We encourage everyone to think about whether their city would make a good DebConf location, and, if it would, to start working on a proposal. (You don't have to be heavily involved in Debian before making a bid.) There will be a chance to present your proposed location at DebConf9 in Spain in July, but don't worry if you can't be there -- proposals will be accepted until the end of the year, and a final decision will be made early in 2010.

Interested? For more information see http://wiki.debconf.org/wiki/DebConf11

This panel will be your opportunity to show your bid to the rest of the DebConf attendees. Although participating in the panel is not strictly a precondition to take part on the bid decision process, it will help strongly show off the pros and cons of each possible venue.

Room: Upper talkroom
Scheduled start: 2009-07-28 20:00:00

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/417.en.html
https://debconf9.debconf.org/

Don't panic!

A few packages within Debian, that also happen to be big packages (Mozilla, OpenOffice.org...) suffer from a serious lack of hands, which is a problem for the maintainers, for Debian, and for the users. This BoF intends at presenting those packages, the typical maintenance tasks, what currently can't be done due to lack of hands, and to tentatively get some more people involved.

Room: Upper talkroom
Scheduled start: 2009-07-29 10:00:00

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/424.en.html
https://debconf9.debconf.org/
Room: Lower talkroom
Scheduled start: 2009-07-29 10:00:00

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/459.en.html
https://debconf9.debconf.org/

Introduction of the new look

The Debian Redesign -> testing 😉

Being one of the most common linux distributions worldwi...

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/390.en.html
https://debconf9.debconf.org/

How does everyone make their Debian-based products?

Toby Churchill Ltd is just one company basing their products on Debian and using cross-building to do it. The process has provided some challenges, including a transition from Familiar to Debian/Emdebian. I hope that others using the cross-tools and repository and build management tools would like to share experiences of how they build things, manage chroots and manage packages, to find out the better ways others are doing things, and what functionality really is missing. Managing cross-dependencies in a derived distribution set of build chroots is particularly difficult - discussion of how to fix this would be really useful.

TCL have based their product on Familiar for several years. They are in the process of moving to Debian, probably in the form of Emdebian Grip. They use dpkg-cross, apt-cross, schroot, and some home-grown scripts for the build process, keeping parallel native and cross-build environements functional. They use reprepro for package management of releases. They do not yet have something wanna-build-like to keep arches in sync, and really should do.

All this stuff is really cool but there are still issues. pbuilder manages native build dependencies really well, but there is no equivalent to manage cross-build dependencies. Well there are (emdebian-tools, apt-cross), but there are real issues as soon as those deps come from a local repository as well as from Debian. I'd like to discuss this and issues that others have found in order to determine how we should best support people trying to do this sort of thing.

Debian and Emdebian should be a marvellous base for cross-building specific apps on top of, and building systems out of, but there is a little more work needed to make this process reliable and manageable. I think a session to discuss the tools and mechanisms, comparing different people's approaches and issues would be really useful.

Room: Lower talkroom
Scheduled start: 2009-07-29 11:00:00

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/434.en.html
https://debconf9.debconf.org/

new features, changes and tips

The bug tracking system is where all bugs that affect Debian are
filed. New features, including the affects, summary, and local debbugs
mirror will be presented and demonstrated. Some of the underlying
architectural changes to the codebase in debbugs to make it more
maintainable and deployable are also outlined. Finally, a set of tips
and tricks that can be used to make the BTS easier to use are
presented.

• New Features
  • affects
  • summary
  • local debbugs mirror for offline work
  • New SOAP
    • full text search
    • filtering bugs
  • multi-distribution/arch status
  • control changes at submit@ time
• Code Architecture Changes
  • Modularization
  • Control abstraction
  • release to experimental
• Tips and Tricks
  • Full text search
  • Using the new options limits
  • Usertags
  • Getting users to triage their bugs

Room: Upper talkroom
Scheduled start: 2009-07-29 12:00:00

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/421.en.html
https://debconf9.debconf.org/

Should lilo be removed?

It was proposed to remove lilo, because of know problems with some configurations. But also grub (and grub2) cannot be used for some configuration. In this BoF I will explain the boot sequence, the status of the main boot loaders (lilo, grub, grub2, extlinux) for i386 and amd64 arch, the upstream plans, and the feature (focusing on the missing features) of the various boot loaders. Then the real discussion: lilo should be really removed? How to "move" configuration of one boot loader into an other, in most transparent way?

Room: Lower talkroom
Scheduled start: 2009-07-29 12:00:00

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/405.en.html
https://debconf9.debconf.org/

no pasaran!

a workshop to improve piuparts. should be held after the talk about piuparts.

piuparts could perhaps be improved a bit. It is a bit slow, maybe, and the log file output requires some experience to be interpreted properly. It might do some more testing. Or some less testing, in some cases. It might test different scenarios. What do you think? Come tell us your gripes, wishes, and experiences with piuparts and help drive its development into a brighter, better future. Our 60 minute mission: to boldly test what no-one has tested before!

Room: Upper talkroom
Scheduled start: 2009-07-29 13:00:00

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/524.en.html
https://debconf9.debconf.org/
Room: Upper talkroom
Scheduled start: 2009-07-29 17:00:00

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/429.en.html
https://debconf9.debconf.org/

A preview of next year's DebConf in New York City, USA

Room: Upper talkroom
Scheduled start: 2009-07-29 18:00:00

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/430.en.html
https://debconf9.debconf.org/

Using Debian as a platform for electronic design and micro-controller programming is completely reasonable, as proven by the success of projects such as those at http://altusmetrum.org. This session is envisioned as an opportunity for sharing best practices and identifying improvements in Debian that would benefit hardware designers.

Room: Upper talkroom
Scheduled start: 2009-07-29 19:00:00

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/365.en.html
https://debconf9.debconf.org/

License, Layout, and Lenny, what next

By this summer, the wiki should have a new license and layout (and CSS hopefully).

We will discuss what we want to to next... some ideas:

• How to implement i18n?
• Structure the wiki by kind of documents (Hardware support, proposals, knowledge base...)?
• Some ideas?

Room: Lower talkroom
Scheduled start: 2009-07-29 19:00:00

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/412.en.html
https://debconf9.debconf.org/

How to give a good install experience on devices that are not PCs

Network Storage Devices (NAS) are are gaining popularity and are available quite inexpensively. For most customers, they are basically just a hard drive that you connect to the network for file storage. In reality, these devices are complete, even if fairly low-end, computers - and Debian can be installed on some of them. Recently, there has also been a lot of interest in supporting other devices, such as netbooks and more embedded devices.

This talk will:

• Briefly introduce the NAS devices we currently support in Debian.
• Explain how Debian and the Debian installer support NAS devices in a very easy way.
• Share the experience gained working with users (i.e. what works, what doesn't).
• Look at future devices that would be nice to support and a number of other features that users have requested.

Do you need more than the abstract? If so, please email me and I'll add something

Room: Upper talkroom
Scheduled start: 2009-07-29 20:00:00

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/394.en.html
https://debconf9.debconf.org/

discussion of the miscelany of tools that build debian installations

Many tools all essentially install Debian, in some capacity, form or fashion.
This would be a discussion of the various tools in Debian used to install
Debian chroots, virtual servers, physical hardware, etc. and what common issues
and workarounds are currently needed, with an eye towards developing more
common code to share between projects.

people interested in the following tools or similar tools would be valuable to
the discussion:

debian-installer
debian-cd
simple-cdd
debian-live
xen-tools
util-vserver
pbuilder
simple-cdd
cdebootstrap
debootstrap
LTSP
FAI

Room: Upper talkroom
Scheduled start: 2009-07-30 10:00:00

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/450.en.html
https://debconf9.debconf.org/

A tool for simplified, declarative unit testing of shell scripts

We will introduce the reasoning for developing a high-level functional unit testing tool for shell code named Shaft
(Shell Advanced Functional Tester) geared towards the GNU Bash shell. We will also provide some key highlights of its advantages and features. The tool was developed at Igalia as part of the testing environment used in some of our projects.

Room: Lower talkroom
Scheduled start: 2009-07-30 10:00:00

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/363.en.html
https://debconf9.debconf.org/

(a cluster of debian machines on your own laptop)

Ganeti is a cluster virtualization platform I help devloping at Google, which can help scheduling virtual machines on clusters of physical nodes, using various virtualization technologies, like KVM and Xen. With this talk I'd like to tackle the "for developer" aspect of Ganeti, and how I use it personally, on a platform which is most probably far away from what it was originally targeted to: my laptop.

The talk will feature an introduction of Ganeti 2.0 as a tool in general, the differences with the previous version (included in Debian Lenny) and its usage on a cluster of servers. Then I'll take a look at how you can use it on your personal development machines, for testing/building packages, testing network servers and protocols, and more. There will then be time for feedback, in which I hope to get suggestions from Debian people about how to do things better, or about features they would find useful for the development of this software.

Room: Lower talkroom
Scheduled start: 2009-07-30 11:00:00

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/456.en.html
https://debconf9.debconf.org/

Results from an empirical study of the Debian project

I will talk about my master thesis about the Debian project. For my thesis I gathered an extensive dataset about all sorts of Debian developement activities (mailinglist, bug reports, uploads, ...). I used this dataset first for some descriptive analysis of the project activity. I studied the growth of the project over time, the distribution of the workload among developers, the impact of releases on project activity, the impact of the creation of Ubuntu on various aspects of project activity and the distribution of the work done on Debian over weekdays and hours of the day. In a second part I verified the hypothesis that reputation and status attained through work done for the project "pays-off". Bug reports submitted by high-status contributors are fixed significantly faster and with a higher probability.

Further information about my research in german (including the full text of the thesis) is available on http://gaudenz.durcheinandertal.ch/thesis/.

Room: Lower talkroom
Scheduled start: 2009-07-30 12:00:00

At: DebConf9
http://penta.debconf.org/dc9_schedule/events/381.en.html
https://debconf9.debconf.org/

Research results revealed

I've conducted a study among Debian contributors to identify the influences that shape our decisions when it comes to adopting or rejecting a new tool/technique into our workflows, or the workflows of teams to which we belong. In this talk, I present some of the findings and offer hints and suggestions for tool/technique supporters to increase the adoption rate in the project.

I have been involved with the Debian Project for over a decade. At first, it
was only a hobby; then teaching Debian to others and planning Debian
deployments became my main source of income. Along the way, my fascination
with the project kept building up and I documented what made Debian so special
in my book The Debian System. I am an active and prominent contributor to
date.

The Debian Project is a highly successful project, run entirely by over 2'000
volunteers, and possibly the largest FLOSS project. It produces several
computer operating systems the most popular of which (Debian GNU/Linux)
provides over 20'000 software packages for eleven different hardware
architectures. Furthermore, the Debian System is the basis for around 150
derivative distributions, such as the popular Ubuntu distribution, and
large-scale, localised installations, including Guadalinex and Limux.

At 15 years of age, it is evident that some of the project's processes did not
scale to meet the tremendous growth we've seen over the years. Endeavours,
such as library transitions, currently require dozens of contributors to work
hand in hand, and often stall because of bottlenecks or lack of coordination.
Day-to-day tasks consist of tedious and thus error-prone tasks, which are
anything but integrated: keeping track of patches, triaging bugs, follow
policy changes, and work with upstream and derivatives, to name just a few…

Looking at the way these processes are currently handled, it seems strange
that contributors of a system as technically sound and universally applicable
as Debian are still doing by hand what the computer should be doing for them.
Tasks like the aforementioned could be streamlined and optimised to avoid
redundancy and points of failure due to brittle integration. For instance,
a bug report should only be marked as done as soon as but only when the patch
fixing the issue has been signed off and appears in the repository.

Some efforts in this direction already exist, but they are not being adopted
as readily as they should be. Because the Debian Project is made up entirely
of volunteers, noone can be told what to do or how to approach their tasks.
Instead, Debian contributors prefer to choose their own methods, based on
criteria which range from technical benefits to ideology, from pragmatism to
sheer stubbornness. In addition, once settled, a developer is often unwilling
to change his/her methods at a later point in time, or may only be able to do
so through considerable additional effort without the ability to assess
whether the effort will pay off.

For coordinators, integrators, or tool designers, no guidelines exist that
could help them frame these criteria and properly cater to everyone in the
target group. Instead, everyone is on their own when trying to spread a new
tool or technique. This impedes upon progress: some ideas may be good, but
never manage to convince more than a handful, who fail to communicate them to
the majority, because they do not understand others' decision behaviours. As
a result, those ideas cannot rise to become competitors with existing methods,
people will have no reason to change, and progress is halted.

A framework of the salient influences to adoption decisions among Debian
package maintainers helps everyone figure out what is necessary to enter
competing ideas into the field, and prevents stagnation due to
unsuccessful "marketing". With healthy competition, only the best tools and
techniques will emerge as winners. And because competition drives progress,
the project should be able to scale better as a result.

Room: Upper talkroom
Scheduled start: 2009-07-30 13:00:00