Minutes of the DebConf19 BoF (was: Re: use Perl; # Annual meeting of Debian Perl Group during DebConf2019)
Hi all,
Here are the minutes of the DebConf19 BoF.
The recording of the stream is also available, see
https://debconf19.debconf.org/talks/51-use-perl-annual-meeting-of-the-debian-perl-group/
The minutes are a collective work: Excellent preparation mostly by
intrigeri and gregoa, Gobby notes taken during the BoF by participants,
collection and redaction by myself and review by Gregoa.
Thanks again to everyone who attended, in person or remotely!
---
Welcome, who's here?
====================
* Introduce yourself if you like
in the room: nodens, intrigeri, bremner, gregoa, kanashiro
on IRC: axhn, carnil
on Jitsi: Tina saying hi
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
NOTE: This has happened in the days after the BoF, including RC bugs
against the packages themselves. Also, porting work has started.
<!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.
TODO: update policy accordingly (at least, the mandatory part in a year,
after
discussion during next meeting).
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:
- No email noise, but no general awareness: only errors generate
emails, and
those are only sent to the person who pushed the patch triggering the CI.
- 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.
QUESTION: Is there a dashboard for teams?
NOTE: When the ruby team enabled salsa-ci after DebConf, they DOSed
the salsa CI runners. Another reason to wait a bit longer …
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 at the sprint was that it was
fixable, provide we allow some exceptions. 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>
Reply to: