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