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/ as "usual", and archive/debian/ 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. ACTION: file RC bugs this week against rev-deps ---------- 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 - 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). - 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. - Shall we start tagging build-deps with 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. - 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) - 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. 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. - 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. - 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. - Disadvantages: - change all repos and add gbp.conf everywhere for no direct gain -