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
Attachment:
signature.asc
Description: Digital signature