Lucas Nussbaum, the current Debian Project Leader
will deliver the Bits from the Debian Project Leader now, enjoy.
Thank you.
[applause]
OK so, I want to start
with the sides of Debian that people encounter.
Usually when people meet Debian for the first time
it's about the technical project.
So we're a project building a very successful distribution
with a real impact on the world
that's really great because
you can go basically anywhere on Earth
and meet people using Debian,
or using Debian derivatives,
who know about Debian
and if you try to wear Debian t-shirts everyday
you will see that many people recognize Debian.
That's really cool.
[from the audience] And in space too!
Yeah, and in space too
But it's harder to meet people in space.
But then we're also
a philosophical and political project
about promoting and defending Free Software.
And what's really cool about Debian
is that we do that
but with reality checks about technical parts
it works like a feedback cycle
between the technical part and the philosophical part.
And we are not doing politics in the blind
we are doing politics while making sure that what we propose actually works.
And then there's a social experiment
with thousands of volunteer contributors all over the world
and bulding this community is a key outcome of DebConf.
And I really think that this place is a fantastic
place to have a successful DebConf that will help
build the Debian community.
I tried to find a symbol better than a good photo
to describe our international community of contributors
and I came up with power plugs
because I think that really shows the diversity of Debian.
So the question I get asked quite often as a Project Leader is
"How is Debian doing?"
and I think that most of the project is working fine.
I decided to single out one team
because usually that team gets a lot of blame
it's the FTP Master team.
Actually probably most of you know that NEW processing had some small issues in the last few weeks
but if you loOK at the data
there are seven members of FTP Masters that
are doing NEW processing since the beginning of July
and, probably, that might be one of the most active teams
in terms of active Debian Developers: seven loOKs like huge!
The DebConf team might have more but still...
and since the beginning of August they processed 284 packages
like in eleven days,
versus only 73 uploads in the queue.
Also we released Wheezy, finally!
It's quite obvious that this cycle
was a bit painful compared to the previous cycles.
If you loOK at the length of the cycle
we're a bit above our previous cycles and the freeze was quite long.
So we started the development of Jessie
with the usual bump of RC bugs
and Jessie will be a quite challenging cycle
we'll really need to work on returning to shorter freezes
because long freezes are not really healthy for the project
and we have some difficult decisions to take:
first one about init systems,
and also I think that in this cycle
at the beginning of this cycle
there are many architectures where the status is not
completely clean
probably we'll need to
have quite difficult discussions about some architectures.
So I think that we should be really careful
making those decisions the Debian way - that is,
make sure to take the best technical decisions
but once the decisions will be taken
I think we'll really need to stand behind the decisions as a project.
We should not let ourselves be divided by the decision.
Debian is almost twenty years old,
and that's an age when most people stop growing
but Debian is still changing quite a lot.
If you went to sleep in 2005 and wOKe up now, probably
the Debian project would loOK very different.
I don't know if you know that movie about
someone getting into a coma
and waking up after the Berlin wall was brOKen down
but could be fun to have someone waking up now,
after eight years.
So, first: team maintenance.
The majority of packages in Debian are maintained by teams now,
since about 2012.
The red line is packages maintained by teams
green line is packages not co-maintained
and the others are: one co-maintainer, two co-maintainers, three co-maintainers, etcetera.
Team maintenance is really the new way to maintain stuff
in Debian, but then we have a problem:
we have teams that get MIA (Missing In Action).
We used to have developers going MIA, now we have teams going MIA.
and actually we are not quite good at detecting that.
When I did the survey about new contributors
one of them had a nice story,
well not so nice actually,
they created a team with only one DD to maintain a set of packages
and then the DD went MIA
and the team was still active
but with no one to talk to to upload the packages.
So it's kind of a lonely island in the middle of Debian
and we really suck at detecting that, currently.
We need to work on that.
Something else is: the use of VCSes to -
that's related to teams, actually - to maintain packages in Debian.
The green line there is Git,
the red line there is no VCS,
and the blue line is SVN.
Git is clearly taking over,
Darcs is increasing, not sure why.
[laughing] the Haskell team maybe?
But Git is really the new standard to maintain packages.
But which way...? We have several ways to maintain packages using Git.
Each team tends to develop its own workflow
with its own packages.
And that really sucks, because as a project
we really need to standardize on a single way
to maintain packages
and not have the project divided into smaller projects
each with its own way to maintain packages.
There's really some work to do in that area,
it would be fantastic if some teams could use DebConf to
come together and decide on a standard way to maintain packages in Git.
And then there are also packaging helpers
the blue line is dh,
the red line is pre-dh debhelper,
and the green line is cdbs.
That graph I always find quite funny because
dh was originally advertised as the cdbs killer
and actually is not killing cdbs, it's more killing debhelper.
[laughter from audience]
But still, that's raises a question: what do we do about
our formal way to maintain packages?
We are quite slow in general
at deprecating the previous standard way to maintain packages.
Clearly dh is now the new standard,
but packages are only slowly
migrating to dh.
Oh, and by the way if you were wondering,
those kind of staircases and steps, there and there
those are the freeze, so you can see that
things slow down during the freeze and start up again, which is expected.
Debian is almost twenty years old
so first I thought that a clarification was needed
as computer geeks: it's in decimal,
and when you see that you can ask yourself another question which is
what should we do before reaching 20 in hex.
Actually I'm turning 20 in hex this year, so it's something I gave some thoughts.
Or maybe... oops! that's the problem with making last minute changes to presentations.
Or maybe what should we do before
well... in the next few years, what are the big challenges.
So first, if you loOK at the global picture around Debian
we have upstream projects, we have users
and Debian is in the middle.
We get software from upstream projects
and we turn them into packages and distribute to users.
And we get feedback and bugs and sometimes patches from users,
and we forward them to upstream projects.
Or we sometimes forward them to upstream projects possibly with adding patches.
But that's not the only thing, we have also Debian derivatives
for which we have the same schema and some of them also have their own derivatives.
And that's really the picture of how it should be,
with Debian really at the center of the Free Software ecosystem,
but some of those are ...
some of those streams don't work so well in some cases.
So one can ask whether we are always
a good downstream for our upstream and a good upstream for our derivatives.
I think there's room for improvement.
In some cases the relationship we have with downstreams or upstreams
is really good
but we can do better in that area
and really reinforce the position of Debian in the center of the ecosystem.
So the simple things you can do:
first contact our upstreams
when you start maintaining something it's really important that you talk with your upstream, if you have an upstream.
So talk to them, ask them to review your plans: if you plan to package a new upstream version
it's good to send them an email beforehand
so they can comment on whether you should do that or just wait for the next release or something like that.
Provide them with feedback and bug reports,
we have some things that are not very well known
such as patch-tracker.debian.org that extracts
patches from Debian packages
so that upstream can easily integrate them.
Ask them to subscribe to the packages in the BTS (Bug Tracking System).
I know for few packages, for example core-utils,
we have the upstream maintainers
actually replying to bugs in the Debian bug tracking system;
and that's just great because users
report bugs in Debian, the upstream maintainer comments on the bug directly in the BTS.
It's the perfect way to work.
Not all upstreams want to work that way
but when they do that way is just fantastic.
LoOK at your downstreams' bugs and patches.
And there's a panel tomorrow at DebConf about derivatives
could be a good idea if we had a large audience attending.
But more generally I think that we need to keep in mind that
Debian is also about improving Free Software as a whole
and we should not work... well, we should work on improving Debian but
we should really keep that global picture
of improving Free Software, improving the world generally.
And for that we need to be a good player and collaborate with all entities.
The ecosystem around us is changing
everybody is talking about cloud, which is
a nice buzzword, but not only a buzzword
and it brings virtualization and elasticity of infrastructure and software.
Ours model where you install a system once
and then you upgrade it for ten years using several Debian releases
becomes less relevant with that ecosystem because you just
start a new virtual machine, you don't need to upgrade Debian that often anymore.
And that raises many challenges for Debian.
First, the cloud - as pointed out by many people -
is taking freedom away from users.
So we need to work towards preserving that freedom
and we have several ways to do that.
For example, we can package software
so that the users can deploy their own private cloud, we are doing that.
We have some margins for improvements there,
those are really really hard software stacks
many, well usually...
many different packages with custom configurations and services
and more manpower on that part would be really nice.
Then we also should work on packaging PaaS stacks
and SaaS stacks.
And standardizing a development platform
and I think a standard platform in Debian is really important.
For SaaS actually we run into the usual problem of web applications packaging
that's not something we're particularly strong at
and it's increasingly important.
But then on a more technical level
the world is using Puppet and Chef everywhere
or is trying to use Puppet and Chef everywhere
and one can wonder what's the role of Debian packages,
package managers and configurations using debconf in that world.
And we might need to evaluate what we do and maybe
adapt a bit to that to better integrate with those tools.
And for public clouds there's also the question of
official Debian images:
what does it mean to provide Debian on a public cloud
such as Google's or Amazon's clouds.
If you loOK at this year's DebConf schedule
there are 8 cloud related sessions at DebConf
and I hope that we can address and work on all those topics.
Probably something that will raise some discussions.
I think we should loOK into meeting all our users' needs.
We have Debian testing which is the first and the best rolling distribution
and I think we should really acknowledge that
and advertise testing as such, as a rolling distribution.
Testing is already widely used:
during the last few days I made some stats
from a Debian mirror
and actually if you loOK at the HTTP logs from that mirror
you see that... well what I did was to take the logs,
grep for people fetching the Packages file
and then loOK at which IP fetches which Packages file.
42% of the users of that mirror fetched
the Squeeze Packages file,
60% the Wheezy one, 12% the testing one,
and 11% the unstable one.
Clearly there are more users... Well,
there are two possibilities:
either we have very few users and many developers,
or we have quite a lot of users using testing
and/or unstable.
If you loOK at the Popularity Contest submitters...
(This doesn't add up to 100% because
one specific IP can fetch several Packages files.)
If you loOK at Popularity Contest submitters,
loOKing at the version of the Popularity Contest package
that is used to submit the results,
we have about 10% of people using testing or unstable
and actually that blue share
varies quite a lot during cycles and
at the end of the Wheezy cycle, just before the release,
it was a lot more people using testing or unstable.
That's not something new: we have lots of people using testing and unstable.
But there are also many other good reasons to go in the direction of a rolling release.
First it makes us provide more recent software to users
so for the Free Software community in general it means
that we build a shorter feedback loop
between upstream projects and the user.
Users can use recent software and report bugs on recent software
because usually when you are an upstream developer
you don't really care about bugs
in software you developed two years ago:
and probably that bug was found in the meantime.
So, the more people we have using recent software
the more bugs are fixed
and the more in general Free Software is improved.
It gets us more testers for the next stable release
so usually what happens... well
it's quite useful from a release management point of view to
detect bugs earlier; this gives us more time to fix bugs.
And actually if you loOK at Christian's stats about
(I think it was Christian who made those stats)
about bug reporting rate
the Ubuntu bug reporting rate is much higher than Debian's
which is a bit worrying
of course if you are the - I don't know - Iceweasel maintainer
you don't really care about receiving more bugs,
probably you have enough and it's pretty well covered.
But if you maintain a quite obscure Ruby library,
it could help to have two times more users, because probably
if you have only 100 users worldwide,
not all of them will report bugs
and it could be helpful to increase the number of users.
Something else is that it makes attracting different users so
if you loOK at the people using Arch Linux, for example
most of them are quite young and enthusiastic Linux users
and attracting more of this kind of users to Debian
means that in the end some of them
will turn into Debian contributors.
Having the image of the old and boring distribution,
which is not completely true but some of it is,
doesn't really help us recruit new people.
We can stay with the old and boring aspect
but is better to have the other side of being young and really active.
And also I think that actually it's a low-hanging fruit because
there's no need to change anything:
it's mainly about PR
about communication, communicating to the public
that testing is usable as a rolling distribution and
just use it and stuff like that.
I think everything is there
we just need to advertise it.
Of course a big challenge with that
is to coexist with the stable release
and to not harm the stable release:
we need to work on... well we don't
...we should be really careful about
not decreasing the quality and the workforce that goes into our stable release.
About manpower, the challenge for the next few years
as usual - as it was for the past 20 years probably -
is to recruit new contributors.
Everybody complains about manpower
it's a regular complaint and I think it's a justified complaint:
there are many areas in Debian
where we could use a lot more manpower.
As a DPL, I often have to pOKe people about
why something is not working as expected
and of course it's easy to blame the lack of manpower but
sometimes when you don't have...well,
sometimes just boils down to that
and you can't do anything beside that.
I made a survey of new contributors,
you might have read the report on debian-project last week,
and what it shows is that it's really hard to contribute to Debian.
As a project we tend to build
very efficient processes
and tools, so we like to
optimize stuff for ourselves,
but as a result those processes and tools are often
quite complex and difficult to learn for newcomers.
That's a trade-off:
we tend to be selfish about our processes and tools.
It's hard to change, but keeping that in mind
when designing processes and tools will already be a good thing.
We have very high quality requirements,
the attention to detail we put into our packages
it's just incredible.
Of course, that's something that contributes greatly to the success of Debian
but still for new contributors it may be a bit surprising.
We have a misalignment between
our contributors' goals and our goals.
What we want really is people who just join our teams
and fix all the team's bugs
and upgrade our packages to the new versions.
That would be fantastic!
Well, people come with an idea
what they want to do inside Debian
and usually it's to package this thing I use
that may be nobody else uses but
that's something that is important to the new contributor.
We need to find a middle ground between what
the new contributor wants and what we want.
And also one thing that the survey showed
it's that is very hard to get sponsored outside a team.
So if you want to package something
and there's a team
where it fits
it's fine: you will probably find
someone willing to sponsor your software.
If it doesn't fit in a team
and you don't know, don't have a friend or colleague
who is a Debian Developer and who will do the sponsoring for you,
then it's really really hard.
You can all help change that: I think it's really
a collective responsibility to change that.
First, subscribe to debian-mentors and
do some sponsoring on debian-mentors
if all of us do one
sponsoring on debian-mentors per month, I think the problem is solved basically.
Problem is, if you loOK at debian-mentors archives
last month, I think it was like four or five
different DDs doing reviews and sponsoring.
We cannot point to something where only
four or five different DDs are active.
And something that is deep in the culture of Debian is that
you cannot make mistakes.
You're not allowed to make mistakes.
And I think that for sponsoring that's really hard
because you are asked to review something
and you cannot read all the upstream code
you cannot audit all the upstream code loOKing for possible bugs.
At some point you have to take a risk to make the upload
and sometimes it's true that mistakes will happen.
I think we need to be better at accepting mistakes.
It's OK to not know everything,
it's OK to not be perfect right from the start,
but it's better to be vocal about things you don't know
things where you are unsure
than to just hide it under the carpet
and hope nobody will notice.
Actually even reviewing packages is something quite hard because
if you miss something, everybody will see it
but I think that's OK, we should really increase the culture of this being OK.
Someone mentioned that one of the people doing reviews on debian-mentors
does a lot of reviews but never sponsors.
So I'm not sure if that's because
they fear that they're going to make a mistake
by uploading something that...
by missing something in their reviews, but that's really sad.
It's OK to make mistakes from time to time:
it's software and you can probably revert it somehow.
It's really hard to break Debian badly by sponsoring something.
There's some work to do on
infrastructure around sponsoring:
mentors.debian.net got re-written two years ago, I think
the current version got the work started two years ago
using a Summer of Code project, I think
It really helps, but there's more to do
for example in many cases
the review is just "oh you forgot that Lintian error"
if we had automated Lintian checks of packages uploaded to mentors
probably the prospective contributor would notice and
this would limit the need for reviews.
Nicolas Dandrimont mentioned that
work is underway there and I think Paul Tagliamonte is working on that.
Something else that is related
to this misalignment between contributors' goals and our goals:
we need to be better at
advertising tasks that are suitable for new contributors.
So if we don't want new contributors to package
another image viewer
we need to provide them with ideas of things they could do.
We have the wnpp-alert
who in the room is running wnpp-alert on a regular basis?
One person. Congratulations. [laughter]
We need a way to make it easier to discover opportunities of contributions.
There are lots of opportunities for contributions, actually.
If you run wnpp-alert you will probably find
two or three packages that you rely on
that are orphaned.
If you find someone to adopt them
that solves your problems for those packages.
We need to design better and simpler
processes and tools and document them.
For example everything related to
using alioth, using Git, using SVN to maintain packages
which is quite poorly documented, currently.
Something that's really really...
It was mentioned that something
really useful is everything related to peer mentoring and internship projects.
New contributors really like
a human contact and having someone to ask questions to.
That's something that...
I don't know exactly how we can improve that, yet.
Andreas Tille has some ideas
he has a session about that
about peer mentoring, but we need to work on that.
In general, basically, what we need to do is
have Debian become a more welcoming project
where people can start contributing more easily
because currently is really really hard.
If you look at the schedule we have seven events related to that, so
the good news is that people care about this
now we just need to make progress on that.
And then, before I conclude my talk,
I want to talk a bit about Debian governance.
I just learnt a new job
and my vision of the new job is that
many DPL tasks are quite short tasks
where if you do them using low-latency
like as soon as receive it it's done, it's much better.
For example everything related to money handling,
email redirection to the right people,
pOKing people about something,
everything related to legal,
where there are some constraints about how long you take to answer,
and all those tasks are quite hard to delegate or to share
because there's a hard coordination overhead
if you want to share them with a team, doesn't really work
because you will spend a lot of time coordinating with the rest of the team
and that doesn't really make sense, you can do it yourself.
But there are also lot of tasks that can be delegated
either totally or partially.
Even writing a delegation, for example
that's something that takes some time
because you need to contact the team,
figure out who they would like to see added to the team
then you wait two weeks because nobody noticed your mail
ping them again... It's quite time-consuming.
And actually there's only the final act of sending a delegation email
that can only be done by the DPL, currently.
Everything else can be prepared by someone else
and that kind of things can be really useful.
So, Zack started the DPL helpers initiative
to try to distribute those tasks to a team
and to teach more people what DPL tasks are about.
My view for that is that
it could be a kind of government for the Debian Project:
you have someone that is
mainly responsible and doing that kind of short tasks,
but then you have a group of people
each with their own area of interest
doing specific things.
For example, we can have someone specializing in all
legal stuff, in all new contributors related stuff,
and those areas are quite easy to define and quite easy to delegate.
With "delegating" in the informal sense of the word:
it doesn't really need to be something official for most of the tasks.
The problem with the DPL helpers is that is not very active.
We had only two participants at the last meeting.
I feel a bit trapped as a DPL
I was hoping to rely on this to share the load
and actually there are not that many people willing to share the load with me.
But I wonder whether this could be the basis for
the most sustainable government model for Debian
something that could work,
and that would allow someone not from French academia
or not self-employed to be a DPL.
Because we're running out of people from French academia!
[laughter]
So there's a BOF about that,
we might mention things going on currently, active tasks,
but I also would like to spend a lot of time discussing
how we can move forward making it possible to move away from French academia.
That is the end of my talk,
thank you for coming to DebConf,
enjoy DebConf, I hope it will be
a very successful DebConf
and I'm quite sure it will be.
Please use DebConf to come and talk to me in person
that's my leader email, which is archived,
and my IRC nickname if you want to ping me
and then we can meet somewhere.
So that's a kind of reminder of what I talked about in my talk
so that you don't need to ask question about
only the last point or only about rolling.
Thank you!
[applause]
[question] About the rolling distribution thing
testing as rolling distribution,
I see a potential problem that has already been discussed
and that I've already raised in IRC:
when the freeze comes,
this rolling distribution would it be freezed?
Would it be intermittently rolling?
Would it be handled differently than maybe
two overlapping testing distributions at the time?
How might that be handled?
[Lucas] Well, I think that
With that freeze duration it's probably a big problem
With that freeze duration, I think we can live
with everything being frozen for three months.
Almost four months.
I think that everyone wants shorter freezes
that would be useful for rolling distribution, so
Let just aim for shorter freeze, let's not try to
do something more complex that might hurt our stable releases.
At this for now, maybe
in five years from now we'll figure out something and
to make everybody happy but
what we do currently I think it's fine.
[question] I don't think three months is an acceptable freeze
I really don't: I mean we'd have this conversation at several DebConfs
and I think a really good target direction for freeze is two or three weeks.
If we can't run a process that allows us to
return unstable to be unstable in much less than a month, then
I think it really negatively impacts the ability of
lots of things in the project to keep growing
those stair steps that show up in many of our plots
are just, you know, very frustrating.
[Lucas] Yeah, but it also depends on what you call freeze actually.
Our definition of freeze is...
well, if we change our definition of freeze we can have shorter freeze.
Shorter total freeze, for example.
[laughter]
[applause]
There are things to explore in that area
like making sure that key packages don't get
upgraded to new upstream versions just before the freeze.
[question] Yes, obviously this is all part of what it takes to
makes something like that happen,
I'm certainly not advocating
a return to the very old process of
"let's just grab a snapshot of unstable
on a particular day and call it a release", but
there has to be something in between
because when we end up in a situation where
for many many months we are not changing
tools chains and core libraries and software
it's very very easy for people to lose focus
and for their attention to move elsewhere
and I think it's very hard for us to get it back.
[question] I clearly remember the talk of Anthony Towns in 2001
at the first DebConf when he introduced the pool system
where testing was introduced.
And somebody else and me raised immediately their hand
"what will happen with packages in testing
and have a Release-Critical bug? Will they be removed again?"
And the decision was "no".
But I think that there's some tendency now
to remove these packages, at least "leaf packages"
which have a Release-Critical bug, and I think it's quite a good thing.
[Lucas] I think that we
should go further in that direction
that is, well...
we tend to treat all packages as equal,
which is nice, because our users rely on all of our packages,
but some of them are still more important than others
and if we had a way to easily detect which are the bugs
that really need to be fixed before the release
and which are the ones that we could just remove the package
that doesn't work, and OK some users will suffer, of course, but
it doesn't block the release,
it would be a good way.
Maybe we should just
go further than removing packages
during the freeze, but also remove packages now
if something is clearly unsuitable
for the next release we could just remove it from testing now,
and if it get fixed, it can get back.
we have at least, almost two years to get it back in testing.
To get it back in shape.
We have very few Release Team members present at DebConf
so it's a bit difficult to discuss that
and it's their main responsibility to decide that
of course they need to talk with the project,
but it's their role to decide about that.
[question] So Lucas, you made two proposals
one is to make testing more rolling release, and the other is to remove more things from it
How you'd reconcile those two?
[laughter]
[Lucas] I'm quite sure we can find the technical solution to that
there are already technical solutions:
people just install packages from unstable from time to time.
And for the users that we are targetting anyway
it's not really a problem if from time to time
they need to take specific...
Actually, if the package is not in testing
and you have unstable in sources.list
it just works.
[question] But I don't think our main problems are leaf packages
You can always say that if there's a bug in a library
then let's remove it, so if there's a bug in libruby, let's remove Ruby and all its packages.
[laughter]
I mean leaf packages are not our problem...
to remove leaf packages is easy and we do that.
Question is what if there's a bug in Iceweasel.
[Lucas] But I think bugs in Ruby - maybe I'm a bit biased about that -
but Antonio can hit you and he's just next to you.
But I think bugs in Ruby are probably the kind of bugs that should be fixed.
Because a Debian release... we need to draw the line somewhere,
but Ruby it's probably on the "let's fix it" side of the line.
Some obscure Ruby library, like rubyfeedparser I'm upstream for that,
nobody cares if it gets removed, well some people will care
[question] So I'd like to propose a radical answer to that question
which is that we should prepared to revert something like Ruby to the previous upstream version
if it fixes Release-Critical regressions, and
obviously that should be done with some care but
it may be done as a NMU, so we need to develop some
collective understanding of when that may be appropriate
and how to manage the fallout.
But if we're able to do that then
we're in a much better position to fix bugs
that are somehow intractable
just by undoing the problematic upload effectively.
[Lucas] But I think that is already happening in kind of
during the freeze, sometimes, happens that
we just revert something to the previous version because
in the new version there are problems.
Often is because the maintainer decided to update and
that was not really a good idea, but
we already have that possibility and we're using it from time to time
I'm not sure it really helps fixing that many additional bugs.
One thing that is related is a kind of
having a feature branch for packages, and having a way to
revert specific changes:
currently we only have one development branch
we could have a feature branch where every package
every new version of a package
lives or sets of packages live
and have them merged into
unstable or testing or something like that
That's lot of technical development.
[talkmeister] I think time is over, so if you want to discuss this further
you have to use the "hallway track".
[applause]