Minutes of the DebConf 2018 BoF: "use Perl; # Annual meeting of the Debian Perl Group"
> The BoF has been scheduled at Aug 03 (Fri), 14:30. That's local time, so
> UTC+0800 - does that work for everyone willing to attend remotely ? It
> might still be possible to move it (no promise), but that has to be soon.
It did happen, albeit half an hour later than initially scheduled:
8 months late, here are the minutes of the Debconf18 BoF. While some
information in it may be old - or stale - I hope it will at least be a
starting point for the upcoming sprints and BoF, or jog memories.
Thanks again to everyone who attended and participated, in person or
And, of course, sorry for the delay.
Welcome, who's here?
* Introduce yourself if you like
Attendees: carnil¹, dam¹, fourdollars, gregoa¹, intrigeri, jidanni², nodens,
ntyni¹, rhonda, Takatsugu Nokubi, xguimard¹
¹ remote, ² part-time
jidanni regularly experiences issues when dist-upgrading his
system with Perl packages that cannot be upgraded.
ntyni replies "unfortunately it's not feasible to have all the 600 or so
arch:any packages rebuilt in experimental at the same time. Sorry."
That's because transitions to new major versions of perl are prepared in
experimental, bugs identified and fixed there, before everything gets
uploaded to sid and the transition to testing is triggered.
* Hamburg: https://wiki.debian.org/Sprints/2018/DebianPerlSprint
Very productive but more people would have been nice.
* DebCamp: https://wiki.debian.org/Sprints/2018/DebianPerlDebCamp
Ditto. Helped motivate at least one person to do some work
from home even if it was difficult (timezone, other
* Look forward: plans for next year
There will be another miniDebConf in Hamburg: June 5-9.
A separate sprint would be fine too.
Low-hanging fruit sessions
* Look back on 2017/18
- 21st of each month, alternating between 17:00 UTC and 19:00 UTC
- 10 happened, 2 cancelled
(vs. 8:2 in 2015/2016, 11:2 in 2016/17)
- 3.0 participants on average
(vs. 6.25 in 2015/2016, 5.72 in 2016/17)
17:00 3.0, 19:00 3.0
- 12 unique persons
(vs. 14 in 2015/2016, 20 in 2016/17)
- between 1 and 8 times, 2.5 on average
(vs. 1-8, avg 3.64 in 2015/16, 1-11, avg 3.1 in 2016/17)
+ packaging: new upstream releases, adopt packages, bug fixes,
+ QA across packages: perl5.26.1, hardening, R³, perl5.27.11,
+ team QA: inactive maintainers, documentation, pkg-perl-tools
+ discussions: alioth → salsa, R³, vcswatch
* Look forward on 2018/19
Do we want to continue? If yes, how?
→ people seem to be OK with the current scheduling (21st,
alternating time 17:00/19:00 UTC)
* commit stats for last year: committer-stats (scripts.git)
- 62 persons with at least one commit in the last 365 days
(vs. 58 in 2014/2015, 56 in 2015/2016, 54 in 2016/17)
- 19 people with > 100 commits
(vs. 11 in 2014/2015, 14 in 2015/2016, 13 in 2016/17)
* ping inactive members:
Not a topic this year due to the Alioth → Salsa move,
during which we added only the currently active team members
(plus DDs) to the Salsa group.
https://bugs.debian.org/902557 transition bug
http://perl.debian.net/ rebuild logs and rebuilt packages/repo
* ~3000 reverse dependencies of perl test rebuilt continuously since
the sprint in May
* Only two known blockers left (in uwsgi and collectd)
* No archive-wide rebuild yet due to lack of resources (disk
space) on perl.debian.net. Would Debian sponsorship
help? → need to ask Dom.
* ntyni is inclined to go ahead anyway once the known bugs are
fixed; no objection to that raised during the BoF. This could
happen in a couple of weeks: the blockers have
fixes/workarounds. Depends on the release team.
Migration alioth → salsa
Look back, and: What's left to do, if anything?
tracker.d.o is in good track to support the use cases
we miss the most from PET :)
Please try dpt-new-upstream in pkg-perl-tools.git :)
fsfs's script to cleanup local repos may still be tied to alioth:
it removes repos from your harddisk which are removed
from alioth (for RM'd packages). OTOH it may optimize mr(1)
runtime / disk space usage by just a few % so some attendees are not excited
at the idea of spending time on it.
/* Update afterwards: The script is clean-mr-repos, and it still works
fine (after some small changes I already made back in March).
Sorry for the false alarm. -- gregoa */
Is it possible to turn off project creation via the web
interface? (That creates unconfigured projects that don't fit
in our workflow.) → ACTION: nodens will check.
Projects for next time, items for discussion
We might have to migrate our mailing list at some point,
when the Alioth ML continuation project stops. It will be
painful to change the Maintainer field in all our packages
in any case.
How to motivate more people to run autopkgtests before uploading?
→ Ask them why they don't use them?