Welcome, who's here?
====================
* Introduce yourself if you like
in the room: nodens, intri, bremner, gregoa, kanashiro
on IRC: axhn, carnil
Sprints
=======
* Hamburg: https://wiki.debian.org/Sprints/2019/DebianPerlSprint
3 people
https://gobby.debian.org/export/Teams/Perl/Team-Sprint-Hamburg-2019
* DebCamp: https://wiki.debian.org/Sprints/2019/DebianPerlDebCamp
7 people
https://gobby.debian.org/export/Teams/Perl/Team-Sprint-Debcamp-2019
Report: https://perl-team.pages.debian.net/docs/sprint-debcamp2019/report-debcamp2019.html
* Look forward: plans for next year
We would like to have a sprint next year again (on top of the DebCamp one).
ACTION: intrigeri will bootstrap the sprint scheduling process in Oct/Nov.
Low-hanging fruit sessions
==========================
https://wiki.debian.org/Teams/DebianPerlGroup/LHF
* Look back on 2018/19
- 21st of each month, alternating between 17:00 UTC and 19:00 UTC
- 11 happened, 1 cancelled
(vs. 8:2 in 2015/2016, 11:2 in 2016/17, 10:2 in 2017/18)
- 2.9 participants on average
(vs. 6.25 in 2015/2016, 5.72 in 2016/17, 3.0 in 2017/18)
17:00 3.5, 19:00 2.2
- 13 unique persons
(vs. 14 in 2015/2016, 20 in 2016/17, 12 in 2017/18)
- between 1 and 10 times, 2.2 on average
(vs. 1-8, avg 3.64 in 2015/16, 1-11, avg 3.1 in 2016/17, 1-8, avg. 2.5 in 2017/18)
- topics:
+ bug triaging/fixing
+ newupstream releases
+ Sprint/BoF planning/reports
+ chats about team policy/standards
+ package takeovers
+ package removals
+ group tools
* Look forward on 2019/20
DECISION: we continue and keep the same Date::Time for now.
We're open to revisiting the Date::Time ⇒ if needed, please say so.
Team status
===========
tl;dr: mostly stable participation according to basic metrics,
maybe slightly decreasing trend though.
* commit stats for last year: committer-stats (scripts.git), as of 2019-07-25
- 57 persons with at least one commit in the last 365 days
(vs. 58 in 2014/2015, 56 in 2015/2016, 54 in 2016/17, 62 in 2017/18)
- 11 people with > 100 commits
(vs. 11 in 2014/2015, 14 in 2015/2016, 13 in 2016/17, 19 in 2017/18)
* ping inactive members:
Last time 2017 with Alioth
ACTION: port the tooling to GitLab during DebCamp20 [bremner is interested].
Perl 5.30
=========
in experimental and on perl.debian.net
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.30-transition;users=debian-perl@lists.debian.org
https://gobby.debian.org/export/Teams/Perl/Perl-5.30-QA
TODO:
- bugs?
- transition bug
Report about playing with dgit
==============================
gregoa and intrigeri have started using dgit for uploads during DebCamp19,
as an experiment. bremner also uses dgit. dgit authors are happy to help.
We (?) feel it's too early to discuss whether we should use this consistently
across the team.
Feedback from our testing
- dgit automates some of the work, e.g. tagging, that some (most?) of us
have automated in their custom home-made private wrappers; dropping
such private code in favour of shared code feels like progress.
- dgit creates 2 tags (debian/<version> as "usual", and archive/debian/<version>
for dgit). dpt-push pushes both (because m/debian/), gbp-push only ^debian/.*.
- The first push needs a weird option. And then one first needs to check
if it's the first time dgit is used to push. And perhaps also if the last
upload was uploaded with dgit. tl;dr: a bit complicated when used
only by a few people on a team.
- dgit adds some sanity checks e.g. that what is uploaded matches
HEAD and what's tagged.
- Met weird issues when pushing with dgit a package that was already
pushed with dgit before. Might have been user error. Needs to investigate
next time this occurs, if ever.
- Supposed to be nice for derivatives (we did not try this though) and NMUers
(tested by intrigeri who loved being able to just cherry-pick an upstream
commit, for a package outside of pkg-perl).
Discussion items
================
Remove unmaintained (quasi) native stuff?
-----------------------------------------
This is about pkg-components, libparse-debianchangelog-perl, license-reconcile,
and possibly other packages that share the same set of problems:
- We are de facto upstream but we are not doing a good job at it:
we are not actively maintaining them.
Note that gregoa does not want to be personally responsible for the
"upstream" work on these tools.
- They don't work well and nobody takes much care about bug reports.
All of them have reverse-dependencies or users. Some of the reverse-deps
are our own stuff :]
Our options:
A. File RC bugs against reverse-deps announcing removal from testing,
port the reverse-deps we really care about away from these tools,
let the autoremoval machinery do its job mercilessly
(hopefully in time for Bullseye), and finally remove from sid.
B. Someone steps up and becomes the upstream maintainer on CPAN, keep
maintaining the packaging ourselves
C. Orphan the packages, port the reverse-deps we really care about away from
these tools, and let whoever still uses them decide what they want to do
about it.
D. Orphan + file bugs against reverse-deps
E. <insert yours here>
ACTION: file RC bugs this week against rev-deps
<!nocheck>
----------
This allows tagging in debian/control Build-Depends{,-Indep} that are
only needed to run tests.
Advantages:
- Shorter feedback loop when building locally and not needing test results:
- DEB_BUILD_OPTIONS=nocheck skips tests
- DEB_BUILD_PROFILES=nocheck skips installation of the build dependencies
that are tagged <!nocheck>
- Helps bootstrap Debian for new architectures.
- Helps cross-building.
- There might be support in autopkgtest some day (to separate build dependencies
and test dependencies).
- For bootstrapping, this is mostly useful for arch:any packages (except for
skipping installation which also speeds up building arch:all packages).
- <insert yours here>
Disadvantages:
- Need to finish support in dh-make-perl (WIP in branch "post-buster")
- Heuristics for automating this won't ever be perfect which increases
the amount of manual work needed when updating a package.
Rebutal: the impact of mistakes in this area is pretty low; and when
one is affected by such a mistake, it should be easy in most cases
to tell what the mistake is and fix it.
- <insert yours here>
Shall we start tagging build-deps with <!nocheck> as a matter
of team policy? Or just keep experimenting with it for now?
DECISION:
1. Recommend this for now and complete the work in dh-make-perl
2. Once we have enough adoption (e.g. in 1 year), mandate it.
salsa pipelines? (salsa-ci)
---------------------------
The Salsa CI Team provides a shared pipeline, that builds package(s) and runs
multiple checks on them after every push to Salsa:
https://salsa.debian.org/salsa-ci-team/pipeline/
Current tests are: reprotest, autopkgtest, blhc, lintian, piuparts.
Advantages:
- It makes it easy to run these tests without having a local setup to do so.
- The pipeline code is shared by every package that "sources" it so
fixes to existing tests, newly added tests, immediately benefit all users.
- Helps newcomers, helps for consistency (shared environment), good for
merge requests.
- <insert yours here>
Disadvantages:
- Email noise on false positives and known broken things? (FIXME: check this)
- IRC noise
- Currently need debian/salsa-ci.yml in each package and a configuration change
in Salsa for each project.
- The full run of the pipeline takes 10 minutes (dh-make-perl post-buster branch)
- <insert yours here>
Shall we enable this for all our packages? → seems too early to tell if/how
it would work for us.
DECISION:
1. It is OK if some of us enable it for some packages, for which they would
like to take benefit from the Salsa CI pipeline, as long as they keep an eye
on the results and take care of it. If this harms the work of other team members,
please say so and we'll adjust/disable/whatever.
2. We should tell the Salsa CI what are the blockers we've identified.
Is there a dashboard for teams?
Policy change proposal about embedded modules in inc/
-----------------------------------------------------
Last december, nodens started a discussion about embedded modules in inc/:
Reference: https://lists.debian.org/debian-perl/2018/12/msg00010.html
During the sprint, we tried to map the issue.
Turns out we have:
* 388 using Module::Build, Module::Install
* 74 using some kind of custom build system or extending existing one
* 21 using a local copy of Alien::* or Test::Base (+ Spiffy)
* 4 using inc::latest
From this, the consensus with people present was it was fixable if we allowed
some exception. A proposal of policy change has been prepared:
https://salsa.debian.org/perl-team/perl-team.pages.debian.net/compare/master...policy_on_inc
Shall we implement this change?
DECISION: We support the idea, check wording, send 2nd proposal to list.
<!-- end of BoF, the following items weren't covered for time reasons -->
R³?
---
dpkg in Buster allows adding "Rules-Requires-Root: no" to debian/control,
so that "debian/rules binary" does not use root nor fakeroot.
Reference: https://git.dpkg.org/git/dpkg/dpkg.git/tree/doc/rootless-builds.txt
Shall we add "Rules-Requires-Root: no" to all our packages that build
fine with it?
Advantages:
- pkg-perl as Debian's Avant Guarde™ has value: we have lots of packages
so we can provide good early testing coverage of such new features,
increasing confidence in the spec & implementation, before they are
enabled by default.
- <insert yours here>
Disadvantages:
- Manual work needed on each package.
Rebutal: presumably "dh-make-perl refresh" or cme could tentatively add
"Rules-Requires-Root: no" if there's no Rules-Requires-Root field yet.
And when we notice the package does not support it, then we would record
this via "Rules-Requires-Root: binary-targets", so we don't have to try
it every time.
- Might become the default later, and then we'd have to remove it again.
Rebutal: while removing it again would be cleaner, we don't really "have to"
do it.
- <insert yours here>
DEP14?
------
Reference: https://dep-team.pages.debian.net/deps/dep14/
Git repo branch layout
master → debian/master
Needs adjusting gbp.conf
Support for change in salsa(1)
Advantages:
- DEP14 gives room (with a predictible namespace organization for tags &
branches) for packaging for anything-but-sid, e.g. derivatives,
stable updates, security updates, and backports.
- If we like DEP14, even if we don't need it much for pkg-perl work,
adopting it on our team would make it more widespread,
get more people used to it, and increase the chances it becomes a
de facto standard elsewhere in Debian.
- <insert yours here>
Disadvantages:
- change all repos and add gbp.conf everywhere for no direct gain
- <insert yours here>