[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Best practises in team-maintaining packages - summary of the BOFs at DebConf8

Best practises in team-maintaining packages - summary of the BOFs at DebConf8


* 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

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

The videos of the BOFs are available at
(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
* Point to the Wiki page(s) in the developers' reference.


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.


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:

Please add informations about your team, and then we can discuss together on
debian-qa on how to go on with these topics.


 .''`.   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

Reply to: