What do they do? There are a bunch of roles that debian people play - developer, maintainer, mentor, packager, administration, etc. Its very cool that so many volunteers can coordinate effectively.
I was wondering how some of the roles involved with debian are blended together - like are there a lot of upstream developers who become debian developers by creating and submitting packages? Are maintainers ever badgered by upstream developers?
As far as I can tell, computer science and software development is not really a team sport - sure, teams work together, but its not like commercial fishing where many hands are used to pull in the net at the same time. Most of the software development I've done has been on my own, and its great that there are communications systems for peer review like irc, mailing lists, and the like, but it must be the role of the mentor that makes debian work so well - or at least all that documentation about policies I keep putting off reading.
I'm always trying to learn about the "story behind the policies" and so I was pleased when Russell Coker posted this anecdotal entry in response to Steve Kemp and Andrew Pollack's discussion about whether maintainers should be proficient in the language the package they are maintaining is written in.
http://etbe.coker.com.au/2008/04/14/debian-work-upstream/
I still have to wonder about the decision making process of packaging and maintaining. How are priorities managed? There are many packages I have no interest in, yet I'm sure they are very useful to others. As an outside/upstream developer, what kind of argument would I need to make to get a package included in the repository? Is it the upstream developer responsible for packaging, and the maintainer or sponsor only responsible for reviewing and sanity check? Does all this vary from package to package, maintainer to maintainer, mentor to mentor, sponsor to sponsor, etc. etc. etc.?
¥