Best practices in team package maintenance, part 2 ================================================== 16th August, 2008 - Mar del Plata, Argentina Gregor Herrmann presents objectives: - Concrete proposals for the collected ideas - Roadmap Topics for discussion: - (meta) communication around this topic? - Recruitment, induction, mentoring of new members - workflows/policies/tools - common "standards" documentation - Maintainers v uploaders - compilation of tools - roadmap Topics ====== Communication around this topic? -------------------------------- lucas: Document in developer-reference. Wiki not a good idea. zack: Use debian-devel for mailing list. lucas: There is already a section in the developers reference. PowerMan: IRC seen as a problem for decision-making - fast, but not searchable. an3as: IRC meetings possible (once a month with a fixed agenda, minutes). fdl: IRC has lack of data after discussions: need IRC logs as web pages. PowerMan: DebConf team has some software [Holger's bot probably] for this; needs someone to chair. gwolf: IRC good for following conversation, not good for documenting. Maintainers and uploaders ------------------------- diocles: Put mailing list in maintainers lucas: bts about to send reports to uploaders as well. zack: Not all mailing lists have the same [sane] configuration. lucas: someone should talk to the admins zack: standardizing on mailing list would be good, but there was not consensus last time we tried this (three years ago). lucas: Receiving mails 3 times is a pain ... gregoa: If group is in Uploaders, we must be sure that bugs go to the group. lucas: The only group who does put the list in Uploaders is Ruby, and they subscribe the list address to the BTS. lucas: In the past, nobody cared about some packages -> responsible person in Maintainer gwolf: This can be solved by having policy that at least one person must be in Uploaders. zack: Point of Maintainers is contact point for the users. gwolf: In pkg-perl, when someone leaves, he doesn't have to orphan packages. Touching any package in perl group leads to adding self to Uploaders and taking responsibility. lucas: Will we manage to standardize on Maintainer being the team? gregoa: Can be a model of good practice. lucas: Should have easily available the GNOME tool to generate Uploaders from changelog zack: Not sure that everybody will agree on using such a tool, but it should be made available. Tools ----- gregoa: Do we need a package for common tools? lucas: I don't like the idea of using devscripts for this - it's large. zack: You are assuming that it is to be used as a build dependency. gregoa: There are two possibilities: build dependency or not. zack: Do we have any other tools? gregoa: The perl group at least has a few scripts, and other groups will have some. lucas: pkg-gnome has a cdbs rule. zack: We are not allowed to generate debian/control zack: Wants something to perform actions on many packages. gwolf: repository-wide changes with tools can afect alioth, so changes must preferably be done as one commit. zack: Separate binary package in devscripts. lucas: It's important that people realise that it's easy to get tools into devscripts, not write wrappers around them. zack: It doesn't make sense to ship web-based tools in a package for a desktop machine. gregoa: Also been talking about DDPO and DEHS, don't know if there's a decision yet on that. lucas: Depends on how UDD turns out, because it would make writing these tools very easy. We are not far from that, maybe a few weeks. UDD is going to move to a faster machine. gregoa: Like the idea of having a central storage for this data. lucas: Need a list of all the tools in use by all the teams, and their features, and then these can go into UDD. gregoa: Send pointers to me if you have not done so already. an3as: Does anyone know about Tincho's uscan-ng? lucas: There are bugs in Tincho's code compared to dkpg, and previous implementations which work. lucas: Send a mail to d-d-l with a report about this BOF, and ask people to mail pointers to tools to you. zack: Afterwards can use debian-qa to discuss.. Documenting workflows --------------------- gwolf: We don't have much to argue on this topic, we just have to do it. gregoa: But if all teams do it in different ways... gwolf: This is geared towards explaining to other humans, so there aren't many guidelines. zack: Wiki page should be pointed to in the developers reference. Recruitment ----------- lucas: There are several problems: getting people interested in debian development, and then getting them interested in teams. If you are interested in debian development, you don't need to have a specific thing to package, you can just come and join a team. PowerMan: I was trying to join a group, and asked on IRC: they told me to start closing bugs. Web documentation was helpful, but not a lot. Had to start browsing all the bugs; group was not thinking about training people to do this. zack: If you are part of a team and want to mentor someone, you can tag bugs as "gift". Encouraging NMs to join teams is a really good idea; brings us back to the problem of knowing which teams are in Debian. Also hard to find out what each team needs from new people. gregoa: Does any team have a structured approach for the induction of new members? - No. gregoa: People then need to be welcomed. an3as: Does anyone have any good experiences with keeping wikis up to date? - No. Roadmap ------- gregoa: First, send out minutes. Then pointers to tools. Deadline of two/three weeks. an3as: Have we got Sledge's survey information? zack: No, it was private to the DPL. lucas: Don't set a deadline - people will wait until the last minute. gregoa: Thanks everyone! I really like working in teams, and especially in this sort of meta-team. lucas: Perhaps we can have a meeting at Extremadura. zack: Might be of relevance to a QA meeting.