On Sun, 24 Aug 2014 15:44:08 -0700, gregor herrmann wrote:
> Just a short reminder: Tomorrow we'll have our annual group meeting
> here at DebConf:
>
> use Perl; # Annual meeting of the Debian Perl Group
> https://summit.debconf.org/debconf14/meeting/12/use-perl-annual-meeting-of-the-debian-perl-group/
> 2014-08-25 11:00-11:45 in Room 329
And the meeting has happened.
Thanks to everyone who attended physically or remotely. I think it
was a quite successful meeting.
I'm attaching the complete notes from gobby (thanks to Harlan for the
excellent transcript and to the others who helped). Below is my
attempt to summarize the important points.
* Introduction
There were over 20 people in the room, and a handful more online on
IRC.
* The team: how are we doing?
- "The team is doing well in general."
- Have we lost momentum during the last years?
Not really, the number of committers is quite stable (and high).
- Low-hanging fruit sessions, wider advertised, might help to attract
more contributors (cf. below).
- Can we make it even easier for newcomers to find the relevant
documentation?
* Debian Perl Group on https://contributors.debian.org
- Tincho is already working on it.
* autopkgtest / DEP8 / CI
- There has been some talk in the past to integrate autopktest into
our packages, and some rough ideas floating around.
- David will poke others during DebConf to work on it together.
* upstream git repo integration into our repos
- 3 scripts for making it easier to setup remotes and importing
tarballs on top of tags are available (dpt subcommands in
pkg-perl-tools).
- Integration needed into our .mrconfig, and into dpt checkout.
- gregoa to poke people here at DebConf.
* patch management
- Currently we have quilt patches.
- Some people would prefer other approaches (gbp-pq, git-dpm,
debcherry) which are more "gitty".
- Let's experiment with them: interested persons try them on some
packages, document them in debian/README.source, and post to the
mailing list and/or wiki.
+ Manoj volunteers for debcherry
+ Niko and Dom already use git-dpm for src:perl, could try with
another package
Maybe have IRC tutorials later?
* Hardening status
- We are quite far for the arch:any packages.
- An easier way to track the status would be nice, maybe building
upon Kees Cook's python tools.
- blhc logs are also avalibale somewhere.
- If anyone wants to improve Kees' tools, talk to intrigeri.
* Low-hanging fruit sessions
- We had some 3 or 4 during the last years -- IRC meetings were we
together worked on some repetitive tasks.
- We want to do this again!
- and publish them better
- and have them on a fixed day every month.
- intrigeri to send proposal to the list.
* Misc.
- Cross-building perl, bootstrapping, multi-arch, ...: Wookey
mentions all kinds of problems -- to check in details with Niko and
Dominic.
- Carton: mikap asks about experiences, Allison explains some
details.
Cheers,
gregor, thanking all people who helped to prepare and run the team
meeting
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
`-
use Perl; # Annual meeting of the Debian Perl Group 2014-08-25 11:00..11:45 in Room 329 https://wiki.debian.org/Teams/DebianPerlGroup/OpenTasks Agenda ====== * Introduction hlieberman is taking notes, and bremner is handling coordination from #debian-perl In-person: gregor hlieberman bremner ntyni dom mika zeha russ Josh Colin Watson Noah Meyerhans <noahm> yi zhang (sp?) ryan maddogs Bill MacAllister intrigeri martin Ferrari martin berends Manoj Srivastava * The team / members / activity / statistics (S): g ntyni: Thinks the team is doing well in general. Thinks that the number of packages that are part of the team means that there are some bugs that slip through the cracks, but quite good overall. bremner: Thinks the number of packages is growing quite faster than the number of team members. Martin F: in 2008, there were 666 packages (at time of my talk) gregoa: We've lost a little bit of momentum and some contributors, particularly during the long 2012-2013 freeze. Some numbers on contributors: git-2011-2012 total: 83, >= 10: 43, >= 100: 13 git-2012-2013 total: 71, >= 10: 45, >= 100: 15 git-2013-2014 total: 84, >= 10: 43, >= 100: 12 The number of committers has not changed significantly over the last few years, though there was a dip in 2012-2013. bremner: Are there statistics for the number of active uploaders? (gregoa: No, but there are more than 3) colin watson: As an occasional downstream of the Perl team, the Perl team is one of the best organized in Debian. The transitions are excellently prepared, with only a few things to fix up. Does worry about the ability for the pkg-perl team to "keep up" with the work. intrigeri: Re: new contributors, more diverse contributors, there's low hanging fruit to talk about later. manoj: As a new project member, there are some barriers to entry that I noticed. It was hard to find the best practices for the pkg-perl group. Not clear how to get a perl package that was already in Debian transferred to pkg-perl ownership. Some need for education for outsiders from the group about how easy it is to follow the standards, get involved, etc. bremner: If you show up on #debian-perl, everything else follows to a large extent. Not discounting that we might need more publicized documents, if you want to join the team, the IRC channel is the best resource to go to. People will walk you through how to get started. ** pkg-perl in Debian Contributors (S): t gregoa: Currently, we don't add our information to the Debian Contributors, so it's a bit tricky to pull statistics. martin ferrari: The project seeks to gather information about how people are contributing to Debian by pulling information from many places. I've got pulled in by enrico (the project founder) to pull information together. In the next few days, all commits that go into pkg-perl git will get updated into the Debian Contributors system. The URL is http://contributors.debian.org * autopkgtest / DEP8 (D): d+n gregoa: DEP8 is a goal to have all binary packages tested, plus integration into ci.debian.org ntyni: We discussed this briefly at last debconf, and came up with a few technical "solutions". It should be somewhat trivial to get most of the pkg-perl modules to declare that the upstream test suite can be used as the autopkgtest suite. There may be some exceptions - need write access to t/, for example - but those can be worked around. Maybe have a hacking session at DC14 to try and get it done? How complete is ci.debian.net? What's it's status, frequency of execution? mika: Antonio might know, but he arrives tomorow. It runs pretty regularly. Think the goal is to run every time the dependency or rdeps change, run the CI tests. gregoa: Will anyone volunteer to take ownership of this, for pushing? bremner: Can take ownership for DC14, but will need to transfer to someone else afterwards. * git-upstream integration (S): g gregoa: Also started at last year's BOF, the idea of integrating upstream's repositories into Debian's repositories. To make this easier, there are now three scripts in the pkg-perl tools git repo that will help. dpt import-orig, should do everything needed. We need integration into the mrconfig so the remote is added when you clone a repository. It also should be integrated into dpt checkout - another candidate for getting done during hacking time. I will remind you all to help. * patch management (D). d+n gregoa: A recurring topic - how do we manage our patches? ntyni: Want to keep this on the agenda as well, because I hate committing patch files to git. There's some conversations going on elsewhere in Debian in other projects - both on debian-devel, the python team. We've been using dpm in Perl core for a while now, and it works great. bremner: one of my debconf tasks is to upload debcherry. debcherry is a tool to treat the debian branch as an integration branch where your commits are part of the overall history and extract those packages at the build-time to build the .debian.tar.gz. If you came from Debian from git, it seems the most natural way to work. manoj: If you are an end user and using git to develop, the flow is to use an upstream branch, your debian branch. The flow is to build your things on feature branches and merge them into the debian package. You never have to worry about editing patches, any of the quilt things. It's just like you use git for every other kinds of development. Wrote a paper on the comparison between dpm and debcherry. The bisectability is orders of magnitude better when using debcherry vs dpm. If you want to look at packages using debcherry, look for packages that I have uploaded - think there are 3. bremner: Want to try this software - sounds great. gregoa: No decision for the moment. We have a long tradition of taking years on this topic. dom: How much homogeny do we need on packaging methods? Maybe have a list of ongoing experiments, and can know to treat those packages with care. bremner: Already do this with Packaging-Helper-That-Shall-Not-Be-Named. Can use a similar procedure where the person running the experiment implicitly trusts to keep the package up to date. Maybe use README.source? gregoa: We need to make sure, in theory, that all the active pkg-perl team members are familiar with any tool we choose to use. Maybe have a class on IRC? manoj: Will write up a README.source for the packages that I am using debcherry, just to serve as an example. Will send out a message when done to pkg-perl mailing list. dom: could ntyni do the same with mod_perl and dpm? * hardening status (S): i intrigeri: Most of our arch-dep packages are built with hardened build flags. No idea of current stats exactly, but it's quite good. Wish we as a team could track our progress in this respect; know if we are doing better than before, and easily identify the packages that need help. Maybe use some of the distro-wide informational scripts? Should just be some python coding. ntyni: Thinks there are lintian tags for the hardening flags. In 5.20, there's a bug that affects 3 packages and means 3 packages have lost their hardening flags. Would be great to notice this in some programmatic way. gregoa: In my experience, the lintian tags are not fully accurate. russ: Lots of false positives. It's a hard problem to detect if you have hardened string functions. Affects multiple of my packages, and I have manually verified that it is a false positive. ntyni: There are also build log checks for this issue. * low-hanging fruits session (D): i intrigeri: Monthly meetings in IRC and spend a few hours working on "low hanging fruits" - things that we can do to help cleaning off our plate on the small, repetitive tasks that are not always fun to do. Forwarding patches to upstream, some of the hardening flag things. Have done 3 or 4 sessions in total, and then coordination collapsed. Do we want to start it again? Should we change the format? How do we make the organization simpler so we don't stop again from the overhead? gregoa: I liked the meetings and would like to see them resumed. dam (IRC): They are totally great. noah: A really good way to get new people involved in things. Problems are simple, easy to get things done, and self-contained. Help make sure that these sessions are well publicized, and see who shows up. dom: Publish them to the project at large? intrigeri: Propose that we pick one fixed day every month to help reduce overhead * debian/copyright: switch to Files-Excluded? (S): g * lintian profile (S): i * Crossbuilding perl Currently quite broken. Make bootstrapping hard. Is anyone interested in improving things? wookey: Right now, very hard to crossbuild perl, and makes it hard to bootstrap things in general because of how early Perl is used. Are there any volunteers for helping with this? Upstream seemed interested in helping to make it better. dom: State of cross-compilation is a little bit better than it was last year. Worth working with ntyni on seeing if there are things that we can pull in. wookey: helmut is having rebootstrap, which automatically builds things every day. I know that perl is one of the problems there. * Perl and the Multiarch interpreter problem Last year's solution doesn't fit with dpkg's view of the world wookey: Last year's solution doesn't actually work. Not sure what we have right now we've actually achieved right now. ntyni: perl core is now multiarch as of 5.20, but didn't go any further than that. mika: Does anyone use carton - the Perl bundling system? (a la npm). Useful for developers who are doing things in a CI context, or a dev context, and don't want to go through the work of packaging it in general. wendar: Carton is miyagawa's work. Does actually generate Debian packages, but not necessarily ones of quality that they could go into the archive. It's kind of like python wheels - a debate if you want to use that in the distro at all. gregoa: Will all meet again next year, and on IRC.
Attachment:
signature.asc
Description: Digital Signature