Hello everybody!
Is there anybody who has seen
my talk on Monday, about Blends or SoB?
Ok, some people. Well, I'll repeat something
only few things, because I think
it became important even more after you've heard the other talk
I'm a little bit astonished because this is
kind of a by-product of my main topic
and this ended up in the main talk room.
What about MoM?
It's called Mentoring of the Month
and Mentoring of the Month was one of my ideas
which came exactly at the same time,
January last year (my own mail was sent one day later
but was just prepared)
and we had one person on our mailing list
who wrote "Dear Debian Packagers, we are looking for one
of you to help us change the history of Healthcare"
actually he was quite engaged and wanted
to have a really large, heavy hospital management system packaged
and we had it on our todo list
but it was so hard that
we would not be able to do it without any help from upstream
because it was quite complex and
I'm personally a physicist and I've no idea about all those stuff, so
I can have the knowledge about packaging
and upstream has the knowledge about upstream program, so
in my opinion this is quite a good fit.
And at the same time
I had written the announcement of the Mentoring of the Month
It was by chance connected to the tenth birthday of Debian Med
and I learnt in these ten years of Debian Med that
there are people showing up and say "Hey, I want to support you a little bit,
I would like to do something"
and then you heard never again something from this person.
Anybody else had the same experience?
In the non-free world
there is a boss and gives money to somebody and
if this somebody doesn't do what he's supposed to do
he will be fired: that's easy.
In the Free Software world is not that easy,
so what to do to get at least some
slight handle on this person?
I came up with the idea to
say "I will spend my time to teach you,
and you are supposed to do some work and do some reports, and so on"
I will tell you how it works in
detail, but first I want to show you another interesting thing
in the Debian Med team
we have about 23 Debian Developers and Maintainers who are
not all very active, but
because we're doing some mentoring
we are advertising this subproject
we have won 10 Debian Developers who confirmed
that they are only in Debian because
Debian Med project exists.
Debian Med is a leaf project
nobody really cares much about it
in the main Debian universe.
It's not important for several reasons, but
even if this small unimportant project can get
ten developers who otherwise
would not be in Debian,
we could do a lot of stuff more.
One point of this is
because we really care for newcomers.
Seven of this people
even dived into other fields
inside Debian,
so, they do not even necessarily be active in Debian Med anymore
and eight of them are working
actively in Debian Med.
What is Mentoring of the Month?
The mentor, currently only me,
but it's not necessarily the case,
just dedicates a part of his spare time,
it's anyway my spare time what I'm doing for Debian
I cut a little bit from packaging myself,
and spends the time for his student.
He should try to guide his student kindly into all secrets of Debian packaging
and I think that learning by example is the best way you can do something
Do some really help to reproduce "hello" packages, which is fine but
it's not full of pitfalls.
real life examples have lots of pitfalls we need to work around
and in this process I've also
faced something which
make some trouble for me and
that it's even more trouble for the newcomer.
If the newcomer has a package he's interested in,
and basically we had lot of these students
that are upstream developers
so have a real interest to get it packaged,
they learn it on the real example.
And it's not necessarily upstream developers,
so the student is free to pick a package
and I, as mentor, have some vetoing rights
just because I have sometimes experienced
that it's too hard to do this in one month
You can say "well, it's nice if you
want to package this, but this doesn't work"
For instance, we have in Debian Med
some kind of todo list
we have this
task pages and we have here some packages
where some work is done in SVN or Git
and you can just continue something already started
or we have
some other things which are not really started
so we have this long todo list
that students could pick from or can do something else.
So, the goals of Mentoring of the Month:
the package in question is finished and uploaded, after one month.
And the student is able to do advanced packaging tasks
and he's also introduced into the communication channels of Debian Med
I always want to make a student communicate
via the mailing list: I personally don't like
mails popping up in my private mailbox
there should be always some public record which you can seek for
and so, communication and the package.
The communication, as I said, on mailing list.
I don't know why, but I always face people who
are too shy to post to mailing list or whatever,
but this is something I really want the student to do.
And other readers might be bothered a little bit by this education
it should be tagged by the
[MoM] tag
so people could filter out or
perhaps there are even people who are only interested in this mentoring and they could read it as well.
I have set five rules: one of these is responsiveness,
so if the mentor is posting something on the mailing list, with a [MoM] subject
the student should really try hard to
to comment on this.
"I have no idea what you mean, can you help me or explain better?"
The student should just respond with something.
It's quite frequent that you post something and
to think that message is received but
it is not really, so this is handshake principle you know from electronics.
You send and the receiver says "yes, I got it".
The student should also confirm understanding:
He should say: "this is ok" or "what does it mean?" or "please, explain"
or he can also say: "I would prefer this or that" over mine, because
I'm not that strict on my opinion,
because newcomers maybe have more ideas about upstream program than me.
So they are way more right than I, or
maybe there's an alternative and I do not want to put my strong opinion
onto this student.
The student should also follow changes, he should subscribe to the commit list
or alternatively should pull from the repository and read the log files.
And the student should also try to find
a useful comment to confirm that
he understand what was commited, because
sometimes I can explain to the student "please do this or that change",
but sometimes it's way longer to explain what to do
than just commit a small change, put a comment on it
and then the student he get also the message, and it's more straightforward.
It's not that I want to do all the coding to put on the student.
If there's something available in the repository,
the student should confirm that he was able to build a package.
You cannot always be sure that students just check out everything
and know the processes of building
I want him to say "I was able to build, and everything's fine, I'll continue working on this"
In case of problems the student should ask on the Debian Med mailing list
also with a [MoM] subject,
and he should show to us that he's working on a problem
so others might join, or not
things should be sorted out via open discussion,
and there are possibly a lot of silent lurkers on the mailing list
we do not even know who is subscribed and who's reading
and perhaps other people could learn.
Alternatively, you could do the MoM with the
IRC channel
I admit I'm not so frequently on IRC, basically only on DebConfs, but
if the student prefers it, we could do some meetings
also to get some faster communication.
And the student should post reports: what he has done,
what he's doing everyday
how was the progress working, and I think these reports are
the way to prove that he's really working
on what we agreed upon, because
I agreed upon teaching this student and the student
just reports back and shows that he understand something.
In summary I can say that Mentoring of the Month is work, for both
but I really think that if you work on it, it also shows that it's fun to work
because both people can learn something
the mentor trades his spare time for the work of the student,
he also tries to train the "silent observers"
and the focus is not only on the technical details but also on learning
to know relevant communication channels
this is also quite an interesting thing because
we have a lot of people working silently on their own and
they do not really know how to find friends.
After hearing the talk this morning, about
the women in Debian, I've seen
that paultag has some statistics about Google Summer of Code's 0% women applicants
out of 181, but in Gnome Outreach Program for Women they had 100 applicants,
I wondered if I should I explicitly dedicate
every second month for women only,
I don't know. I don't know if it helps because we are quite a niche project
if there are really so much women but I could consider to try this
if other projects might adopt this idea of MoM
it could be some way to help also here.
As a result we had in the first year
four MoM periods and in this year one,
I've not students every month, so well..
And the most interesting thing is actually the first one
it's not yet uploaded
but in this MoM work, upstream learnt that they need
to change their build system and changed a lot
and so we need to wait for the next upstream
which is supposed to happen soon.
And finally we got something into Debian, or will get something really soon
which we never managed over the ten years of Debian Med existence.
This is a really valuable thing,
to train people
because otherwise we wouldn't manage that.
Finally I think this is
kind of a good result
it also have that people put their name in the queue,
we are using a wikipage, I'll show the link at the end
there's a table and you put your name on the table
it's quite informal.
Some people consider doing it, and say "So, what can I do?" as I said I cannot fire anybody
As a conclusion,
I think the time spent into mentoring is really worth the effort.
Because you have not student for every month, the workload is bearable
somehow, so I think it's not very much more than
what I'm doing anyway, because
I do not restrict my teaching work on the mailing list to this project:
I'm teaching on the mailing list anyway.
And so it's a little bit more formalised and a bit more strict
and hopefully inviting.
And actually I'm also learning myself, because
I've been a Debian Developer for fifteen years
and not really sure if I have read every document which should be read
and specifically I have not read them in the last ten years.
So, the student is new and reads the documents and I'm learning
I'm really learning a lot of features
I would never have learnt if I wouldn't have done this teaching
The major advantage for me it's that by the training
we could pool the knowledge of upstream
and ours of packaging stuff and this is a very efficient way
to get packages which are really hard for us to do.
So, Sponsoring of Blends: what does it mean?
Well I learnt that the Blends concept is
widely unknown amongst newcomers
and also amongst the Debian Developers.
I'm talking about Blends since
2003, DebConf3
and with different names,
but people are widely ignoring this topic
or think "that's a cool idea but we have no time to do it".
And, well, this is fine: everybody can spend his time as he wants.
But the thing is that newcomers might desperately seek for sponsors
and simply don't know how to find one.
But in principle every Blend should
have a team around and should be
really involved in sponsoring the packages.
But some Blend doesn't fly in the sense that
there are some maintainers having a package
and asking for sponsoring on debian-mentors list
So, what can you do?
I think we could kill two birds with one stone.
We can get the packages sponsored
after proving that you understood
the Blends techniques
Think about this.
I personally want to
make some Blends concept way more popular than it currently is.
And the maintainer of the package which could be in a Blend
is seeking for sponsor, so we can find a common solution.
Also here, there are some rules: Sponsoring of Blends means...
The first rule is the maintainer should confirm
that he understood the Blends principles, he has read Blends documentation
is a member of some team on Alioth or reading the development mailing list.
I've frequently observed that there are ITPs
or an ITP list
which are relevant for - say -
Geographic Information Systems, Multimedia, Games
and these people are single maintainers
not really connected to a team, and
I would say "Would you consider
maintaining this on GIS team, or in Debian Science team
to get some connection to people?"
I really hope that if
this seek for sponsor
makes obvious that the person has no contacts
I try to get this contact via the Blends.
Second rule is that your package is maintained in a VCS
used by the Blends team
the technical background behind this is that we are
checking the VCS with Blends tools and it shows up here
so if your package is in SVN
all the informations are updated from SVN
if you really put your package there
you have to do nearly nothing for it showing up in that page.
One thing is to make the
sponsee aware of this, and the other thing is that we get the information straight
Your package is listed on the Blends tasks pages,
which I've shown you, which is really really easy:
you just put an additional line in the Control file.
It's very easy and then after one day
when the cron job is running, it is there.
They will know about your package
and you get some extra chance that somebody might pick it and sponsor it.
And the fourth rule is that if you are unable to find a sponsor
on the specific Blend list, even after posting there at least twice
I will sponsor it for you.
You should seek in your own team,
and if the team doesn't go with it, I will do it.
So these are the rules.
This concept is quite new and we have only two
cases for the moment:
one was sponsored and it was fine,
the other one... I sent him some change requests
saying "please change this and that" and
got no response.
I think two or three months.
The question was "How new is new?":
I do not really remember when I announced it but two or three months.
And I'm also lurking on relevant mailing lists and
I'm reading debian-mentors and
I'm trying to catch maintainers in need of a sponsor.
I'm also lurking, for instance, on the lists of derivatives
OsGeo distribution which
is a Ubuntu derivative
and in principle competing with the Debian GIS team.
They don't know each other, they also want to make
a GIS distribution of Free Software,
they don't know of each other,
they also don't know that there's a Debian Java team but
there would be some need,
and they're asking questions like "how can I package
Java applications?" then
I've written to their mailing list "well, there's the Debian
Java list" and then nothing happened.
If I see that there's some package near to be ready
I post to them
"you could get into Debian straight if you follow these four rules".
I think this thing is new, so I'm always
sending a link to the wikipage
and hope that something will happen.
If you might notice that there's some candidate for this
Sponsoring of Blends rules, please redirect them to me
I hope I can bear the rush you put on me now.
This is what I just put on the slides when I was sitting in your talk.
Mentoring of the Month, Sponsoring of Blends, and also face-to-face meetings.
I'm coming to the repetition of what I've said on Monday.
I want you to have a very quick look to
what happened since 2011 when we started doing yearly sprints in our team
and in these sprints we are not only Debian Developers
there are upstream developers and users.
About 20-25 people
sitting together, we had in 2011 in January
last year in February, and this year also in February
and the effect is really amazing.
By the way, thanks to Debian for sponsoring those sprints
You see here the usual statistics, you might ignore that
I'm always this large red line
but what you see here
in 2011 you have a solid base compared to this one
these are newcomers
and these newcomers are constant
and actually these people who are longstanding (these are longstanding ones)
may drop their activity.
In 2011 you have some obvious
increase in the upload of Debian Med packages
next matrix is the discussions on the Debian Med users list.
You see quite the same effect, right?
We have another thing: the Debian Developers mailing list
also 2011
it is an increase, a measurable increase.
Who is fixing bugs in the Debian Med team?
You see since 2011
a lot more people fixing bugs.
And commits to the Debian Med VCS: same effect.
It's quite consistent.
And finally, in the packages we have in Debian Med we have a lot of biology packages
and at the sprints we had actually
biology developers.
So the increase is in this biology section, you see here?
The other are quite constant increasing, but
you don't see this increase.
If you meet face-to-face with interested people
you get some drastic effort for your project
even if it such a side project,
a leaf project like Debian Med.
I can't stop saying that if we would do all this stuff
in Multimedia, GIS, Games or so, we could have lot of more people
We always have the discussion here, and
in the two talks, or three talks I've heard
that people have trouble finding friends in Debian on
IRC or on the mailing lists.
Well, it's not that hard
the answer is create inviting teams around certain topics.
If somebody comes to Debian
with a certain interest
and everybody has some interest to
install Debian
they shouldn't do it otherwise.
It should be natural
for me, if I am a biologist
I'm looking around at what distribution has the most
biology packages,
"ah! that's Debian! Let's try it!"
and then you come and see there's a team behind it
and then you will contact the team
this is kind of a natural thing since 2011 or so.
Formerly there wasn't so much, so
create strong teams and
you will make it very easy
for others to find new members for a team.
This is my definition for a team:
waking up in the morning and realizing
that somebody else has solved your problem from yesterday.
I really have realized that
we have some Debian Developer in the team
who just joined the Debian Med team because it's fun in this team.
He's Thorsten Alteholz, he's not connected to biology
or medicine anyway, but he said
"Well, that's fun, let's join it"
and he's doing QA work, and he made some
in December, some "Advent Calendar"
to push people to fix a bug everyday
to close the windows.
This is very fun and it works
because we try to invite people.
So, these are some links:
our policy document, which is also helpful for newcomers
maybe this is even a fourth point that a newcomer can read,
the main point is how to behave inside a team.
Mentoring of the Month, Sponsoring of Blends,
and well, that's basically all.
I will upload this PDF document
you can click on the links.
And now, well, I talked
two thirds of this BoF
I just want to hear new ideas
and any comments.
Raise your hands, please.
[Geert] Can you tell us more about organizing sprints?
[Andreas] Yes, I think there's a mailing list debian-sprints@lists.debian.org
There's a mailing list, debian-sprints
and there you can announce that you want to do a sprint
and then you should create the wikipage
with some informations given,
and you fill in location...There's a template you just fill... Lucas?
[Lucas] Yes, about sprints: please organize sprints, we have
the budget for that, if you think it's useful for your team,
just contact me at the debian-sprints mailing list, and it's really easy to organize it.
[Asheesh] If I understood the question correctly, it was about
what are the steps required to organize a sprint?
Can you explain the steps?
You began to talk about there's a wikipage, but
then what do you need to know, what planning do you need to do
how do you invite people...
[Andreas] Yes, ok. I'm very happy that somebody in our team is doing all the work for this
and I just have to come to these sprints, that's nice.
He is caring for
some hotel,
we have the rule to meet at some place at the beach,
it was in Luebeck, it was in Southport,
in England, and it was close to Kiel.
Find a small hotel, preferable with some better bandwith that we have chosen,
but yes,
and then try to find people, and this person in our team
has a very good ability
to attract people I would never have think about, he's
writing emails to people
"Hey you have this package, and you might be interested in this and that
and please come to our sprint"
and he wrote to fifty people
and twenty or so have come.
This is a good mix of Debian Developers and
other people and this makes some point, but even...
There were even Ubuntu people at these sprints
and even from a derivative of Ubuntu
which is called BioLinux
and the effect of our first sprint was
that these BioLinux people are now using the same Wheezy as we,
so we are working on the same code.
And as a package migrate via Ubuntu to their distribution
and if they have changes we incorporate it and
if we do changes they have it as well.
So this is quite efficient.
Try to find friends for your project.
And then put them in one place, and lock the doors!
Serve them pizza and cola or whatever.
[Asheesh] How long do your sprints last,
and how many have you run, since 2011?
[Andreas] We have run three, once per year,
and they run from Friday afternoon to Sunday evening.
We can also keep on talking about this other mentoring stuff.
Fifteen minutes left, barely.
If you have other ideas how we can get new developers
or how we can create a friendly environment for men and women.
[Franklin] Do you think it would help
to have more Blends for not so specific
users, maybe...
let's put names... What about having your Blend for XFCE desktop
or multimedia desktop?
[Andreas] Yes, I think that is a good idea,
because you say "not so specific"
you need to decide how narrow you make the focus of your Blend
For instance, in Debian you have a GIS team and an OpenStreetMap team
and both have common packages and both have separate
I don't think this is a good idea, you need to
get some critical mass,
to have ten developers, and not three there and five there.
And then
it could fly. For instance, if I'd started with Medicine, nobody
immediately connects biology with medicine, but
biology was a lot of stuff
it was there, we used that. And so this build some creative base and then
other things came around.
Try to make it large enough to last some time, to get some critical mass.
[Asheesh] I think that the idea of Blends is really interesting, it sounds almost like
a collection of people who use Debian
who care about some topic or packages, and the fact that there is a Blend
is almost separate
from the fact that it's just people interested in a topic or packages,
there's no reason you couldn't have like Debian e-mail sprint, or something.
[Andreas] You can do these sprints on any topic, yes.
[Asheesh] The thing I'm trying to think through is that
what you're talking about Blends it just makes me think some
notion of teams
and I guess I'm struggling to see the difference between Blends and teams
and maybe we should try harder
to make more topical collection of packages being in a team.
[Andreas] The Blend is actually a team working together on a certain user-oriented topic
It is user-oriented for certain
for certain work fields, and you have some tasks in it and
my idea was just to attract
people who are not necessarily geeks
but just want to do their normal work with Debian.
I assumed that we would have way more Blends and I pushed
the principle on people
I wrote this stuff for the DebiChem team, all the frameworks I put on and they said "that's nice"
And they use it now.
And there's also the Debian Science Blend which is actually...
actually we should have Debian Mathematics, Debian Physics, Debian
Electronics or so, but there is nobody
really engaged in
separating things out and make a real team around these topics
We would need such people who are doing this.
[Asheesh] If I understand correctly, the core concept of Blends
is that Debian when installed contains all of these packages, is it right?
[Andreas] Yes, the Blend is completely integrated into Debian
[Asheesh] But it's not just that it's integrated, there is an installable
a sub-installable Debian...
[Andreas] Well, it's installable as metapackages,
we would like to have something to say about
create a DVD just with the Blends,
we have the idea, asked once on IRC,
you could put it on tasksel, then just select your Blend
there is an open bug reported, from 2003 or so, which is tagged "wontfix"
[Asheesh] It sounds to be like
- and I haven't thought through this carefully so it just may be crazy -
that we should just rename Blends to Topics.
[Andreas] Yeah, the naming topic... You have not seen my talk,
the name of Blends changed over the time, I can repeat it if we have time.
It was first Debian Internal Projects, and we wanted to split from
this technical projects to user oriented, this was
somehow logical, and then
somebody suggested Custom Debian Distributions,
which also was a total failure because, if you heard the...
You are smiling, you know!
Well, I suggested
Debian Internal Solution, or something like this
which sounded not
that bad in my opinion but
once I did this, people write that... I've never seen these people before, I've never
seen any code from them, they're not supposingly on the mailing list but
once there was a name we wanted an opinion on
they raised their hands, they said I have an opinion
we should not use this name, we should use something else.
And then there was some voting and
now it's called Blends.
I don't really want to go this street twice.
[laughter]
[Franklin] I personally see quite some
use for Blends for
having people be able to provide
multiple variance of Debian for security
maybe a live CD for security purposes
and some of them might be overlapping but...
[Andreas] There's also now overlap: we have overlap between DebiChem and Debian Med, so there is overlap
[Franklin] and I think it's fine to have them overlapping
it just is a way of having people not forking Debian
just for specific needs, it comes to have people working inside Debian
and contributing inside Debian rather than forking and having their own
[Andreas] For me is... A Blend is kind of making a Debian derivative the right way
by staying inside Debian
and maybe you finally can do
some nice background, and release something that's your product but it's inside Debian.
[Asheesh] I think the key concept you have about keeping the work inside Debian is well taken.
For me, I kind of didn't realized that Blends...
I thought that the point of Blends was to create non-derivative derivatives.
Like an installable Debian Med image
or whatever the package is called,
So it seems like we should try
to run around all of the users of Debian and
who have friends who are DDs
and say "Is there a topic in Debian you care about? Create a Blend today!"
[Andreas] This is what I'm doing since 2003.
Ten years of doing this...
[Asheesh] I'm sorry that I'm so late to the party!
[laughter]
[Andreas] This is actually my point
I was with this Blends
topic, I was degraded to the second talkroom and there were
basically people that are medicine or so related
and other people think "well this stuff
it's not interesting for me"
And now I'm here for
getting a larger team and people...
I get more attention perhaps this way.
On my next DebConf, in my talk
on Blends I will find a funny title, and talk about it
and let's see!
Any other question? We have five minutes left.
[Phil] Is it easy to discover the metapackages that make up a Blend,
at the moment?
[Andreas] I hope so,
there's a common prefix also
[Phil] Ok but...
do we have some submenu on the expert install or whatever?
[Andreas] Well, we could have a lot of them but the effect
that is that tasksel stuff was not accepted
[Phil] Well I'm not talking about tasksel, I'm talking about the
initial install
[Andreas] The installer or whatever.
[Phil] You could... you can say which default desktop you want installed,
you can have a parallel menu on the first bit of the Debian Installer
with the menu being constructed automatically
[Andreas] Whatever way
you're suggesting, I'm all for it!
I can't really show this here now but...
[Phil] The point with that is that you could
probably include udebs in your Blend
and change the nature of the installer at the same time
[Andreas] Most probably but
we are lacking the technical manpower on this.
So if anybody have some ideas, I'm all for it.
There's also a frequent question
"Do you have a DVD?" and I say "Well,
this set of Debian
DVDs is actually our work but people want this one."
This is a Debian Med or whatever, so you can do it easily by
using Debian Live and put all the metapackages on it, then you have it.
Or you can do some other clever trick, but this would be nice if somebody would do this.
What I'm always doing these webpages - which has now vanished because network is goin - contain everything
translated with popcon stuff,
... maybe it's working again ...
No, no network. Whatever, I don't know.
Maybe it's back now... Yes, it's back.
What I'm advertising is
we have all these translated descriptions what belongs to the Blend
so if this colleague of mine
(I made it also for my colleagues who are working on
a different operating system
and using sometimes Free Software, while not being aware of this)
We have all these applications, you have screenshots
... you should have screenshots on the right...yeah! we have screenshots
Ok, you can upload screenshot if it is missing, you can translate,
here's just a German locale to see that it's really translated, and everything of this come from UDD
so the only thing you do to structure your Blend is say
Depends: packagename, Depends: packagename
and everything is done with this framework
we have dedicated bugpages, so that if a biologist wants to help Debian to fix a bug
he can go to the Biology topic and find the bugs in this. And we have other tools
which are ready for any topic.
It just needs to be used.
I will run other BoFs, Debian Multimedia, Debian GIS and Debian Games and try to do it.
At DebConf11 I was sitting at the Debian Games BoF
and it was 45 minutes and I started from scratch and I made for them a template of framework
up to this webpages
There was no change until now to put another
games or make some other task...
I'm lacking the knowledge about games
this knowledge needs to be put into the framework
and perhaps we'll make sometimes out of this or
try to re-write Debian Junior or so
[Miriam] The problem with games is that they are so different
that you would probably need to compartmentize that because
for example is not the same
kind of people who play
Quake and play
I don't know, chess.
Probably in Debian Junior or
or how we decide to call it, it might be
quite easier because the age range is different
but we would also might need to
separate between different...
[Andreas] I'm sorry if I interrupt you, but that's not really the point
we have hospital information systems, biology, medical imaging
this is as far and different things like
Quake and Frozen Bubble.
We just need to
find the right category.
[Miriam] Is there a way to make like tags, or something like that, to filter
similar packages, like for example, I'm interested in this kind of game develooment
[Andreas] We can do it.
Time's over. Thank you everybody.
[applause]