Best practises in team-maintaining packages - summary of the BOFs at DebConf8 =============================================================================
Preface ------- * First of all please accept my apologies - I promised to write this summary shortly after DebConf but ... * I'm posting this mail to -devel (to reach a broad audience) and to -qa (because I think improving the way teams work is an aspect of QA in Debian), RT and MFT set to -qa. * The following summary can obviously contain my interpretations and might misrepresent some of the discussions; I invite all participants to correct any errors. The BOFs -------- During DebConf 8 in Mar del Plata two BOFs about "Best practises in team-maintaining packages" took place, the first as planned beforehand, and the second at the request of some participants of the first session in order to discuss things further. I'd like to thank again all the participants for the IMO very productive work and especially Tim Retout for taking notes and preparing the minutes of the sessions. The objectives of the BOFs as defined beforehand were: - bring members of different packaging teams together - get an overview of different work flows, tools, and challenges - compile generally useful 'models of good practise' - define possible areas for cooperation / tasks of mutual interest The complete minutes can be found at http://lists.debconf.org/lurker/message/20080815.023943.bf7a5f27.en.html http://lists.debconf.org/lurker/message/20080817.235345.667b162b.en.html The videos of the BOFs are available at http://meetings-archive.debian.net/pub/debian-meetings/2008/debconf8/ (615* - 617* and 823*) The first BOF started with structured mini-presentations by members of several packaging teams (cf. the minutes above). The second half of the first BOF and the entire second BOF then tried to focus on the challenges and open questions that teams face in their work: Tools/work flows/policies ------------------------- A question was: "Would it be useful to standardise the work flow between packaging teams, or to standardise the documentation for their work flow to make it easier for others to find the relevant information?" Some of the opinions/proposals: * Use the existing mechanisms (e.g. README.source for packages and wiki.d.o/Teams for teams), and spread the word where this information can be found. * Have an "abstraction" package per-team containing team work flow documentation; better than Wiki; can contain cdbs class or README.source files. * Point to the Wiki page(s) in the developers' reference. Maintainers/Uploaders --------------------- Question: "Would it be useful to have a common policy for Maintainer/Uploaders?" (i.e. whether Maintainer = team and members in Uploaders or the other way round) Most of the present teams put the team in the Maintainer field. That approach makes dealing with the BTS, with user or maintainer requests and also with retiring people easier. It was also mentioned that it's important not to restrict people helping out on different packages. One team preferred to have a "human maintainer" (and the group in Uploaders) in the past because of bad experiences with people dumping packages in the group's repository and disappearing afterwards, leaving the question of responsibility for the package unanswered. Also discussed where approaches of creating the Uploaders field automatically from debian/changelog; the GNOME team seems to use a tool for that purpose that would be nice to have as an option for other teams to. In the end of the discussion there was a tendency to use the group in the Maintainer field; changing the Developers' reference (5.12), which mentions both possibilities, doesn't seem necessary at the moment, the present teams want to act as models of good practise for the time being. In the long run it might be good to standardise the definitions of the terms "Maintainer" and "Uploaders" for team-maintained packages by policy. Tools ------- A large topic was the question of collecting existing and developing new tools that are especially useful for packaging teams. At the moment many teams have their own command-line scripts or web-based tools. As a first step a list of existing tools should be compiled. Some aspects: * Converging existing tools seems desirable; e.g. we now have UDD, PET, buildstat, DEHS, ... * Having a package for command-line tools, cdbs-snippets, ... that are used for working on groups of packages or help in building team-maintained packages (maybe devscripts-team, built from the devscript's source package?) seems useful. * Some of the web-based tools could be made available on Alioth automatically (e.g. PET). Recruiting people ----------------- A bit of time was also spent on the question on how to recruit new members for teams and how to integrate them. I seems that none of the present teams has a structured approach for recruitment and induction; some thoughts were: * Invite people on ITPs or sponsoring requests, or people who want to help and don't have a specific thing to package, but a more general interest. * Work in a team must be fun. * Be friendly to new guys; people need to be welcomed. * Provide good documentation about the team's work flow, tools, policy, ... * Tag bugs as "gift" to mentor someone. * Encourage NMs to join teams. The participants agreed on the statement, that it is good for the groups and for people entering Debian to learn from a group rather than only from reading policy and Google. Road map -------- I've set up a Wiki page for collecting tools that are relevant for packaging teams: http://wiki.debian.org/Teams/Resources Please add informations about your team, and then we can discuss together on debian-qa on how to go on with these topics. Cheers, gregor -- .''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/ `- NP: Donovan: Cuttin' Out
signature.asc
Description: Digital signature
