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

[Debconf-discuss] BOF "Best practises in team-maintaining packages" - protocol



The BOF has taken place today; thanks to all who participated and
shared their experiences and ideas.

Tim Retout had agreed to take notes during the talk and provided me
with an awesome protocol - thanks alot, Tim!

I'm attaching this protocol to this mail; my only changes were a few
formatting things and some minor additions off the top of my head
(all grammatical errors are of course mine :))

As requested by some attendants at the end of the BOF I'll try to
arrange another BOF for Friday or Saturday, so that we can continue
the work.

If you are a member of one of the teams which has tools that might be
of general interest please send pointers and short descrptions to me,
I will try to compile a list.

(The protocol and the slides are also attached to the event in
pentabarf.)

Cheers,
gregor

-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian gnu/linux user, admin & developer - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-    BOFH excuse #73:  Daemons did it 
Best practices in team package maintenance
==========================================

14th August, 2008 - Mar del Plata, Argentina

Gregor Herrmann presents introductory slides.

Structure:
- mini presentation per team
- collect topics for discussion
- discussion
- summary

Mini-presentations
==================

debian-med, Andreas Tille
-------------------------
* Mailing list communication
* Attract members at debconf
* Infrastructure: QA-related web pages: bug overview, packages and
  descriptions
* Sponsoring for non-DDs
* Someone has written a policy covering package structure/VCS
* Using repository on alioth
* Some tools to build the web stuff
* Interesting to look at who posts to mailing list
* Need to make team have more than one active member
* Be friendly to new members
* Ask them to give an introduction
* The team is working well - small user group, not so many packages, makes
  things easy

debian-science
--------------
* Mailing list
* Not only a packaging team - fallback for packaging when package isn't
  covered by another team
* Share experience
* Four people
* Repositories on alioth
* Very new
* Has a written a policy
* Tools: git
* Challenges: to welcome new members always, because specific knowledge
  required
* Takes advantage of the debian-med tools
* Follows ITPs with debtags, should be more integrated
* Even if someone outside debian-science is packaging it, can see on
  qareport

debian-voip
-----------
* Mailing list, also via SVN commit logs
* Infrastructure: private buildd farm, builds svn trunk once per day,
  including sid, backports and Ubuntu packages
* Several non-DD members who commit to SVN
* svn with svn-buildpackage and upstream sources in svn
* No regular workflow for non-DDs getting packages uploaded; bump DDs on
  mailing list
* New members often come from them filing ITPs and then joining team
* Experiences: generally positive, often performs updates quicker than
  single maintainer
* Sometimes difficult having to learn different tools for each team

debian-ocaml - zack
-------------------
* Mailing list, IRC channel
* SVN repository, slowly moving to git
* Enables commit access to every DD, but this isn't often used
* Web report
* Own policy since 2002
* No team-specific problem, but collaboration difficult when every team has
  own conventions. Lack of a common way to document team-specific procedures.
* No common usage of distinction between Uploaders and Maintainer between
  different teams

debian-perl - gwolf
-------------------
* Organised around PET - web page to see overview of needed work
* Also coordinate on lists and IRC
* Alioth repository accepts commits from non-members
* Packages listed in LowNMU
* PET aims to remove need for RFS mails
* Communication via "invalid" changelog entries (i.e. notes at the top of
  debian/changelog)
* Work with svn-buildpackage
* Great success story, good integration

ruby-extras - lucas
-------------------
* Very different to debian-perl
* Fairly standard team
* svn-buildpackage
* cdbs class for ruby packages
* uscan
* Difficult to know who is reponsible for packages within team ->
  one single responsible person per package (in Maintainer)

Comment by Tincho: Important not to restrict people helping out on different
packages

pkg-gnome - kov
---------------
* Mailing list, IRC
* Quite a few active members, two or three who push the work forward
* Always trying to recruit, gnome large and complex
* Bug triaging is a challenge
* svn-buildpackage, with gnome team-specific layout
* Some work being done on gnome policies, but mostly already integrated in
  debhelper
* Does have interactions with other teams, but mostly these contain the same
  people
* Status page

Comment by gwolf:
* pkg-perl recently discussed whether to move to git, and decided that we
  would be using VCS in a centralised way
* SVN tree is huge; on the other hand in the ruby group, the upstream
  sources are not tracked, which is a different way of working

Comment by zack: Would like better tools to make changes to all packages in
a team in a batch fashion.

Discussion
==========

Tools/workflows/policies
------------------------

Would it be useful to standardize the workflow between packaging teams, or
to standardize the documentation for their workflow to make it easier for
others to find the relevant information?

zack: We already have all the necessary mechanisms (e.g. README.source for
packages and wiki.d.o/Teams for teams), so it is probably just a matter of
spreading the word

lucas: Have an "abstraction" package per-team containing team workflow
documentation; better than wiki; can contain cdbs class or README.source
files

Maintainers/Uploaders
---------------------

gregoa: Would it be useful to have a common policy for Maintainer/Uploader?

lucas: Didn't Ganneff file bugs on package with non-human maintainers?

gwolf: pkg-perl always has human Uploaders

lucas: Possible to automatically update Uploaders with recent developers

zack: Need package with common tools like this

(Tools)
-------

an3as: debian-med has web interface with task files

gregoa: If people send me descriptions of the various tools, I could produce
an overview

zack: Right now there are a lot of tools, but they are opt-in; it would be
good to have them enabled by default on alioth, e.g. PET for svn-based
packaging teams

In general converging the multiple tools (and at least making them better
known and easier accessible) seems desirable.

(Maintainers/Uploaders)
-----------------------

zack: It would be good to standardize the definitions by policy.

Members being reponsible for specific or all packages
-----------------------------------------------------

lucas: Some people came to the ruby team, dumped the packages on them and
left. The goal of adding at least one person responsible for each package
was to know who to ping when there was a problem. Others can of course help.

tincho: In practice, if you really know some package, you will work on it
quite often, and people will know.

gwolf: The main reason why this works so well in pkg-perl is that CPAN
modules are so homogenous, so new packages are not so much as a burden; the
same thing might not work in other teams.

kov: It would be good to have some kind of decision on what should be done

lucas: ruby-extras sets Uploaders to the team mailing list address, and
maintainer to the really active person

Recruiting people
-----------------

"grabbing" people on ITPs or sponsoring requests

tincho: It is good for the groups and newcomers for people entering Debian
to learn from a group rather only from reading than policy and Google.

work in a team must be fun!

Next steps
==========
- collect infos about the various tools (please send info to gregoa)
- another BOF at DebConf

Attachment: signature.asc
Description: Digital signature


Reply to: