We are pleased to welcome Lars Müller to the Samba Team. Lars has been following the Samba project for a couple years now. Lars began with Samba as a part of Linux admin work at the University of Göttingen. There he was also involved in the creation of a campus wide network for students. Later, he started to work as a Linux support engineer. Both jobs required that Lars build customized Samba packages. He is currently in charge of Samba at SuSE Linux.
Lars began very early in his work at SuSE to submit all of his modifications upstream. He has actively worked with Samba Team members to coordinate the inclusion and maintenance of his patches and has shown his commitment to Samba and Open Source/Free Software by attending several events and conferences.
The following is taken from an email interview conducted just after Lars accepted the invitation to join the Samba Team.
You've been working on Samba for awhile now. Do you see being a part of the Samba Team affecting or changing the way you work on Samba?
Above all I expect some extra work. As I got the feeling of an open, communicative, and competent Team at mailing list, IRC and events, I expect an improvement to my technical and social skills. I'm far away from being bugfree in both directions. ;)
But back to the question: I don't expect big changes in the way I work on Samba as I already tried to align all of the Novell/ SuSE work regarding Samba with the Team as close as possible. Therfore Samba.org efforts and my daytime work shouldn't conflict. I hope the opposite is the case and we'll have benefits for both.
The biggest difference results from the write access I'll have to the subversion tree. My old position allowed me to open bugs, attach a suggested patch, send a mail to samba-technical, and ask one week later if this patch was garbage.
Since you started as a sys-admin, how did you move into Samba development? Was this a difficult shift to make?
Mostly missing features and problems reported by customers moved me to Samba development. I started with reading the Samba lists, rebuilding packages, and grabbing single patches. But it happened that a problem wasn't addressed upstream or wasn't solved acceptable for a Linux vendor. IIRC we had such a situation with CUPS and raw printing. That was the time when I started to get a more detailed picture of the Samba source code. And cscope and ctags are still very helpful.
In my case it was a slow and not so difficult shift. It was slow as I first did support and on-site consulting. Here Samba's debug levels were gold. The output redirected me to the source code. As I had programmed in C before it also wasn't a too difficult shift.
So what will you be working on now that you are part of the Team?
I'll try to help with open issues in bugzilla to reduce our bug count. Beside that I'll try to enhance Samba 3. It's our bread and butter release at the moment.
Lately I worked on migration issues. That work included a new sub command to the net tool to print a report of the content of an existing share.