Wiki

• FrontPage
• RecentChanges
• FindPage
• HelpContents
• DebianMed/MoM

Mentoring of the Month (MoM)

In this effort the mentor dedicates a part of his spare time to a newcomer (the "student") providing any packaging knowledge the Mentor has to enable the student working more or less independently on packaging after passing this MoM period. The mentor will guide the student kindly into all secrets of Debian packaging at the example of a specific program which is in the focus of the Debian Med team. The student is free to pick the package however, the mentor has a vetoing right in case he sees the package in some way as "unfit for the MoM project" (too complicated, too non-free, too far away from Debian Med topic, too whatever). At the end of the month the goal is that

1. The package in question is finished and uploaded
2. The student is able to do advanced packaging tasks and is introduced into the communication channels of Debian Med team

The communication about this should be tagged with "[MoM]" in the subject line of the exchanged mails to enable others who might not be interested to procmail it out of their focus and enables other potential students to learn from this.

In this MoM process I would like to apply some strict rules:

1. If the mentor is posting something on the mailing list containing [MoM] in the subject the student tries hard to respond with any comment (if not better possible something like: I have no idea but I will do some research like asking upstream or whatever - just leaving a hint that he feels responsible somehow).

2. The student tries to follow any of the commits of the mentor to the package which is in focus of the MoM plan and favorably sends a comment like
   • Its OK for me
   • What does this mean, please explain
   • I would prefer ... instead of your change

   To get informed about the changes the student needs to be subscribed to the commit mailing list or checks regularly the logs in the repository (svn up | git pull; {svn|git} log). He just tries to find a useful comment to any commit just to make sure he has understood things and will be able to do it himself in the future.

3. The student confirms that he succeeded in building the package according to the state in Vcs in case it builds or he is able to reproduce the error message of the build process.

4. If there is any problem the student will ask on the Debian Med mailing list (tagging the subject [MoM] to not spam others to much.) This list should be the main communication channel to show others:

   1. we are working on a problem
   2. how things could be sorted out via open discussion
   3. how they could learn things about packaging

   Communicate can also be done via #debian-med IRC channel

5. The student post a status report about the packaging every day reporting about changes he did, issues he faced or discussions he did with upstream etc.

Please be careful. The MoM plan is work. While it is intended to show that work can be fun the mentor expects the student to do some work in the same way as the mentor is offering a part of his spare time to do the other part of the work which needs to be done. So the mentor will ask the student whether he did his part of the work. If not the mentor will stop the work on this package and will continue with another MoM student and his package (in case there might be a waiting list).

The MoM effort was created in the hope that we will be able to train those silent observers of the list to become more vocal. This training not only provides technical knowledge. It turned out that this is only 50% of the job. The other part is communication which is heavily underestimated. By communication we do not mean plain chatting. It is about communication that leads straight to a technical implementation.

Current mentors, students and packages

Students in the queue

• H. Soon Gweon packaging meme

Helpful Links

For newcomers in the Debian Med team the most essential reading is the Debian Med policy document. Please put it under your pillow. It helps the student to in the initial phase when having first trouble with checking out via ssh as well as giving useful hints later.

Summary of past MoMs

15. January to 29. February 2012: Luis Ibanez packaging fis-gtm

Luis Ibanez took over the challenging task of starting with one of the very hard packages in the beginning. So the result that the package is not uploaded yet does not come unexpected. From a mentors perspective I'm happy with Luis because he learned basic packaging skills and communication channels inside Debian Med and did a pretty good overall job. He was quite verbose about his plans and success / problems so it was quite easy for me to guide him. For the package itself he started to rework the upstream build system using cmake which is probably a good idea anyway and helps other potential users outside Debian as well (which is a good thing). I will keep on helping to finalise the package once Luis will confirm success in getting cmake working.

1. March to 31. March 2012: Scott Christley packaging libswarm

It seems Scott Christley was not able to spend a comparable amount of time as Luis in the first MoM period. On the other hand Scott was not totally new to Debian packaging and there existed some preliminary packaging of libswarm in SVN. When he tried to finish the package it turned out that another precondition (libkawa) is needed and filed an ITP bug #666238. The plan is to finish this package first.