Hi everybody, thanks for coming to our last talk, the only draw we have is there that you
just all, you know, funneled in through. This one is not available. Please try to, I don't
think anyone's going to slip out early from this one, but I don't think any of you can,
obviously, I'm going to give you that. But do try to be quite the tables to make a lot of noise
and up and down, and if we have a lot of that, this is what I'm going to do with that.
It's that two minutes early, and I think that recording starts already. So whenever you're
right, you just go. Yeah, I can start. I'm really happy to see so many people,
welcome everybody. Thank you for your interest in Debian. And well, just to start,
I had this talk about the birthday, and I thought it would be a good idea to express this in
binary. And in the key of the I had this talk, they made even a cake. So we are Debian is now in binary
1, 0, 0, 0, 0, 0, 0 years old. And I think this is quite some age. It makes,
well, my, I'm a Debian developer since 1998. I started using it in 1996. This is more than half
of my life. Something, well, I started with punching cards, and this is, I've seen quite some
things in, in IT world, and I think given it's the greatest for me. And since one year and
nine months, I'm a Debian project leader, it is a job I would have never imagined that I would
do it at all, but maybe someone here in the room is also never imagined that he or she will be this,
but you can never be sure. So because to for me was this, is Debian relevant these days,
because you have a lot of distributions and whatever. And my main argument that it is relevant
is the so-called pop-com, pop-com popularity contest. If you're in Saudi Debian system,
do you please say yes, if you're asked that you want to try and pop-com, then we know what we
are using and we can care for the packages we are using. And the fact that the most used package
in Debian, which is here, well, it's pal-based, but you also see it's growing the graph. So
that means we have more and more users who are switching on pop-com, and I'm proud about this.
What the correlation with my term is probably, I don't make this call, this is just the same time.
I think I did not contribute to this, actually graph. I'm also happy that Debian is tested.
We have auto-packaged tests, so we have some CI running. This is also continuously increased,
which is good, because I think this is a good feature of Debian that we are testing,
but we are distributing. We have also some interesting features about package maintenance,
and here I think I contribute a little bit because, at the top before, said it's about
maintaining the package in a common forge. We decided for a GitLab instance for people who cared
to adjust it, and I have put some focus that we have really all Debian packages in this GitLab
instance. Since this graph means we started with no version control system, 100% of packages
in 2006, and then we had some hostings called Elliot, which was replaced by salsa, salsa,
GitLab instance, and you see the green graph is what we now have in salsa, and this graph,
which is not maintained in Git, is decreasing, and here is the start of my term, and you see,
here was a more or less horizontal line, and I feel responsible for this small thing.
But it's a lot of work, right? I come back to this and you see the corresponding line there,
and also interesting effect is this is the trick series release, and after the trick series release,
you see some steeper curve, I come back also to this. So this is about team maintenance
package in Debian, we have for historical reasons. Each package belongs to maintainer,
because when we started with Debian, we had a lot of very good experts for some packages.
But meanwhile we have 60,000 packages, we don't have 60,000 experts for every single package,
and so we are migrating more or less to team maintenance, and I'm thinking it's a good idea,
because in Debian we are all volunteers. We volunteered to do something, but we did not
volunteer to tell the other guys, oh, I'm stopped using or stopped doing anything, so we people are
just managing, and they have no good control about people who just leave Debian silently,
they get children, which is the best reason to do something else, they move away to collect stems,
whatever, but they will not tell, and so we have a problem to detect this, and so if we
move more to team maintenance and lose the strict maintenance, then this could have a good effect.
So I'm not coming back to this after the release is the curve, so we have in Debian we have
releases, these are the red lines, and before release we freeze the actor of state
of the package pool, and only fix release creditor bugs. This means if you only fix release
creditor bugs, you can't open your features, and you can't do this or that, and you see for every
blue line, which is the start of the freeze, the activity drops, and then there are several
leaves, and this goes up. You always can see that this was a migration from
earlier to Salsa, so this is an artifact here, and always also the last
trigger release, it stopped, and then we started working, and the same effect was also
supposed to be by the curve was more steep, because silently people kept on working, and then
they in the upload came and then something happened, so we have no really good solution,
then trying to make the period very short between freeze and release.
So if you want to help Debian and to avoid this, I call it freeze depression,
please help us fix single release creditor bugs. When we are faster, because Debian releases
only, if you are ready, it really means no release creditor bugs, and everybody can contribute
to this, and so you see the time spent are shorter than before, you would to several
scenes and so on and so on, but it could be even shorter. So there are the people
contributing to Debian, you see, these dots are those places where Debian developer
provided their personal data. Some people do not want to provide it, but most of the Debian developers
are about 1,000 people in the world are sitting in these places, you see Europe is quite densely settled,
Northern Americans, Northern Americans, some people in Asia and some people here, I have a different
representation of this. This is the number of developers per country divided by the number of
people inside the country, and you see Finland is winning. Yeah, it's great, we had a great
Debian Finland in 2005, which is really cool, I liked it a lot, maybe it's also some influence
by no care in Finland, you say about supporters, but it's probably also the reason that
in Finland are not so many people. Like here in China, we have probably the absolute number of
developers in China as higher than in Finland, but if you divide it by being so, it's,
but it's interesting because on one hand this graph shows where there could be potentially
more developers, and it also shows the problem in the world, so there you have white spots
between to reach out, we invite people to Debian conferences to get connected. The next Debian
conference will be in Santa Fe, so the red lines are where I joined the Debian conference,
you see, I was on Debian, the next one is Ruby in Santa Fe, they will be most probably
no red line for me because I need to break because I will also stop serving as DPL in April,
but I can only invite everybody to join the Debian conference, that's why I'm hiring this T-shirt
to do some promotion for them. It's always a cool event, Debian conference really great,
so if you like to go to Argentina, it's a good option to join Debian.
So regarding the money we need for, for, for, for, for instance, that comes to me.
This is the graph you had, so it shows we had quite some money at some point in time, but it
also decreases again. If you have some money, we can use money for data and for everything.
Specifically for debt conferences, this is the main amount of money, so if you are a company,
you could put your, your logo on the t-shirts for gold and platinum spondos and you could
support or meeting because if we, if some Debian developers and contributors come together,
this is a really cool thing and inspiring ideas come up and everybody will have profit for me.
So yeah, to, if you want to know how to donate, it is on the Debian website and donations.
Yeah, what, what can I do for you to come to Debian? We try to create an invite environment.
I'm doing a lot of workshops. I'm doing the workshops in the way, I'm asking the audience,
what do you want to package? What do you want to see you in Debian and then we start
packaging your software. This is a kind of practical experience and if you are lucky,
the result is one more package. Well, beyond the way to get to new package,
I'm also trying to do the back of the day. This is an initiative where I try to fix
one back per day and I did really want back per day, starting at the first of August in
2024 and this is also when the curve started to go up or going out of the horizontal tendency,
because we also brought, we did not only fix the back, we also chosen, we have chosen a package
which is not yet on size, and we bring it on size to demonstrate how to do this.
We try to support local meetings, local meetings can be
mini-tabcon, we have a very strong Brazilian and very strong Indian community.
They are doing yearly mini-tabcon, which are really great. They are doing a really good job.
In Hamburg, we'll be a mini-tabcon this year in May and if I think in the second week of May,
so Hamburg is close to Brussels somehow, just join us.
And we also try to simplify packaging, and a lot of stuff has happened in last year,
and basically David is providing some metadata in the control file and the make file,
which is called David Rules, and in the best case it's a two-liner.
So this makes things really easy to package, and yeah, we have always need for newcomers,
so please don't assume David is so great, we don't need help, yes we need you,
we need everybody who wants to contribute, because we have a constant flow out of David,
and so we need the constant flow of new contributors, preferably also,
we need this contributors, because we are quite male dominated, we had some.
This is interesting because 10 years ago, we had kind of statistics, so in IT, women are 25 to 30 percent,
in free software, women are only 15 percent, and David is what's even lower.
I have no explanation for this, and it's hard for me to change it, because
the only way to increase percentage of women in baby and is to leave David,
but I would prefer a better idea, so if women would come, this would have a better effect.
So if you consider to become a David developer, is anybody in IT, what is the most important
feature of a David developer, and the slide hint is that it took me 20 to years,
until a bug I filed was finally fixed, so any ideas, what is the most important feature?
Exactly, patience is the most important feature, so yeah, please be patient,
and in many ways to get the official David and developer status to get some packages in this
part, I'm quite proud that I think I've found the solution for this, and you also
need some skill in communication. Communication, what should I say? We are
technicians, we are in some ways socially focused on technical solutions, not really to communicate
to people. I learned a lot when I was a David project leader, my wife told me, I got better,
I'm proud about this, and I have an actual hint for you, if you have
if you want to write an email, which is complex, not simple, just write it and let it in your draft
follow, for one day, it helps a lot, sometimes you will not send it, then it was no need for it,
just let it let it matter for a day, and then you should always answer your education,
is my mail contributing to some solution, or do I just want to, I'm not happy about this,
blah, blah, blah, this is also in many cases, not really helpful, and what I also did for
well, as a David project leader, you are writing really complex mails, I asked people for peer
review, so what do you think about my draft, is it good, it is good at this time, you can
have better use of better wording, also this is extremely helpful, and if you have no peers,
also, maybe you ask an LLM for help, right, ask this, make it productive, kind, non-acgressive,
this could enhance the discussion, I'm not in general saying, just use, I know, but for this,
specific thing, there is even some scientific research that I tend to make conversation a little bit more
friendly when we are used, then we usually are interesting, or no way, and we also should try to
remove some blockers to other productivity, what do I mean with this, in everybody of us in the
room is very busy, or somebody who said, no, I'm not busy with it, so you are busy and then somebody
needs your help, I'm too busy, I delay it, I have the principal to say, first I help the person who
needs the help, because if this person is idling on the IM working, but if this person can continue,
then two people can work, so please always try to give preference to help others first,
this is what I mean by doubling the productivity, so what I did as a DB and project leader,
so it first I needed some kind of warm-up, learnt something, and after three and a half months,
I started with this bug of the day thinking, I think it was a success because some people
really started to do more work and package themselves, became a DB and maintainers and we also had
some positive effect in the package pool, then we had this, for me it's the right thing,
just the tell our community, the shouldn't support X anymore and provide very, very good content to
somebody who is more excellent, I don't know, this had a lot, thank you, but you give up now,
but we get a lot of lot of angry males, it's not democracy, it is bad, I mean the decision to
pose on Twitter once was also non-democratic chosen to publicity himself, oh, let's post on Twitter,
there was no decision, and then there's decided, we have other ways to communicate,
let's stop to this, oh yeah, so thank you for that class, then we had to upload,
this is actually not really my, there was a lot of preparation, what is tech to upload,
usually we are doing a manual process to upload DB on packages, and some people were very busy
for five or six years to say, okay, everybody is working in kids, let's just take some status,
and this will be done as an upload, this is a modernization of our workflow, this is cool,
but it was complex and a complexity was realized on the technical side, when on the social side,
it's always, and well finally it happened, it's not really not only my work that it happened,
but I think it was something that could be listed here, then I did a new publicity team
delegation, which was also a complex social thing, and depth conference always in very,
very good way to discuss with developers and create new ideas, I was discussing changes
in the FTP master team, FTP master team is are the people who are checking new DB on packages,
if they are compliant with the DB on free software guidelines, this is an important thing to do,
and so we make sure that no non free software and those are archive, and they are also running
all the technical stuff, and I had seen, at this time, problems with this team, we discussed this
in the first stage, and I also discussed about all fan packages, this is the problem that people
just manage and don't do anything anymore with their packages, then most of the tricks are released,
it was great and not only, well, not much for this, except of fixing some RC boxes,
this is a community effort, we had Thursday, 32, Thursday, also binary, I like this,
and as a result of the discussion of the DB on conference, I have split the FTP master team
into an archive operation team and the DFSD team, this was a suggestion actually by a member of
the team, because in principle, these teams had two tasks, one is checking new packages,
for legal license issues, and the other task was running the archive, running the software,
which is distributing packages, and this leads to rotating the delegation of this part of this
format team, the DFSD team, if a member of the new DFSD team here, I'm really happy that she is doing this,
and we all hope that this is for, in the long term, for a more transparent process,
more predictable process, and will be for the profit of DB on it. So, as I said, I will not run again
for the first time, for DPL, and for the last three, once I hope that I will be able to
work a little bit on the problem of often packages, and my aim means missing in action,
we have a team, which is tracking down DB and developers who are missing in action, and this team
is missing in action, and yeah, this is a problem, and I also try to get even more
packages, because I think it's, it's good for cooperation. My favorite lessons for my
term as DPL is formally, I was working very hard for the DB and mid project, this is about
this is a DB on pure blends, for bioinformatics, and I was very active there, and the good
thing is I told my team, I need this time, I spent for the team, I leave you alone, if you are
responsible, I will not contribute to the team anymore until I'm back after being the, and the
very good news is that this team is keeping on working, so if you think about free software projects,
where the main driver is not active anymore, a lot of them, not really work, but I'm really happy
that this is not the case here, and they are working really good. I also learned that you say something
and no response, and this is the hardest to interpret thing, and so well, I had to
optimistic person, I think, okay, then people agree with me, but sure if it is the case,
but they should tell me if not, and I also have to learn that if you, but DB and project leader
is not the person to have to say much, you can do delegations, but other thing is if, as a leader,
you say something, and then you say something, and the volunteer can decide if this is relevant
or not, or whatever, so also have no real power, but anyway people, if you meet people, it's
all they need, and I think if we, we friends are treating me like before, like just Andreas,
find your friends, this tells you, so you can tell the real friends who not look at ranking,
but on the person, and I also learned that I made mistakes as everybody, and I learned that it's
a good idea to say sorry, I made a mistake, and I was really lucky that finally these mistakes
did not have so much bad effects, so I reached the goals, I wanted to reach, and it's also
good lesson. Yeah, that's all for me, time for questions.
Hello, I'm Lucy, just speaking on the subject of, I would highly recommend we watch your
Marcus Kino from this morning, if you haven't seen it, that might be relevant, but my question to you
is, when your retirees do you feel, do you have any ambitions for what you might do in the project next,
the question was, if I will return to debiamate or do something else, I had observed that about
50% of the DPLs we came MIA, I hope so, I will not do, yes, I plan to go back to the debiamate
project and keep on working there, this is my plan. More questions.
You displayed the map of the computer so that there was a lot of fight? Yeah.
Zero, white is zero, yeah, for this is, yeah, zero, even one would be dark blue or so.
Yeah, I would love if we could have more contributors, right?
The debint developer's right, if there might be contributors, this is correct,
official debint developers with a debint.org address, thank you for the, for the
volunteers to provide their location. Yes, if you have a debint developer from here,
who is not providing the location, I don't know, but the probability for this is,
right, I think we have people who are very keen on the, on privacy are more or less located here.
It's, it's my guess. No questions.
Feel free to ask, yeah, partly, yes, the question was, was it fun? Yeah, I think it was,
I learned a lot and learning something is somehow fun. I could have other fun inside even,
I always had fun, but yeah, I think I, I don't regret that I did it.
This is also, there was, yeah, there are recent trends in software about to work by passing
distributions. Are you concerned about that? The question was, there are trends of bypassing
distributions. Yeah, yeah, a bit cargo and so what they're about to talk here about cargo,
and, well, from, I have personally experienced with packaging arpecaches. I'm with this
science field. There's a lot of bioinformatics stuff and actually arpecaches are really easy to
install, but what we are doing is you have a scientific package with which needs
are, these are that others. And we have, indeed, when we have dependencies, so we want to have
a complete, I'm completely running application and if this application needs the arpecaches,
we included, so we package this. This is for, for the arcing. For cargo, I was thinking about
it when hearing this talk, if you have static linking and have a really, the time is up to
onto this question. I have a really low level rust package. Then you have to rebuild everything,
but cargo has no means to resolve dependencies and so on. And I think, for the moment,
as long as cargo has this deficiency, we should package it and also for PIP is similar,
or I'm preferring the packaging. We also, I've seen a short slide about testing. We are testing
that what we distribute as a whole with all these tiny version dependencies will work.
I don't think that is the case for PIP or cargo or whatever you have. We have, but
I can't tell about the future, but for the moment, I think it's a good idea to build the
advantages. I think we need to save it, we can extend a bit to the last talk. I don't mind.
If there are really urgent questions, if you permit, if you permit, that we have more questions.
Oh, they can ask me anyway without audio, so all to come here.
Thank you.