Sean Whitton

An opportunity to meet the members of the Debian Technical Committee who are in attendance at DebConf, hear the status of open issues, and discuss pending and future issues.

Other people: Gunnar Wolf Matthew Vernon Helmut Grohne Christoph Berg Elana Hashman Niko Tyni

Consfigurator is a system for declarative configuration management using Common Lisp. You can use it to configure hosts as root, deploy services as unprivileged users, build and deploy containers, install operating systems, produce disc images, and more. Some key advantages: - Apply configuration by transparently starting up another Lisp image on the machine to be configured, so that you can use the full power of Common Lisp to inspect and control the host. - Also define properties of hosts in a more restricted language, that of :POSIX properties, to configure machines, containers and user accounts where you can’t install Lisp. These properties can be applied using just an SSH or serial connection, but they can also be applied by remote Lisp images, enabling code reuse. - Flexibly chain and nest methods of connecting to hosts. For example, you could have Consfigurator SSH to a host, sudo to root, start up Lisp, use the setns(2) system call to enter a Linux container, and then deploy a service. Secrets, and other prerequisite data, are properly passed along. - Combine declarative semantics for defining hosts and services with a multiparadigmatic general-purpose programming language that won’t get in your way. Consfigurator is particularly well-suited for deploying Debian systems because it was written by an experienced DD. But moreover, I see Consfigurator as part of the project of bringing over to Debian the best ideas we find in contemporary alternatives to Debian-style package management, like the GNU Guix System and NixOS. Tools like Consfigurator and Propellor try to layer the power of declarative and reproducible configuration semantics on top of traditional, battle-tested UNIX system administration infrastructure like distro package managers, package archives and daemon configuration mechanisms, rather than seeking to replace any of those. I'll share some of Consfigurator's unique features that might make administrators of Debian systems interested in using it, and explain how one of the project's goals is to get as much as possible out of all that existing distro policy-compliant work.

Like every year, during DebConf21 the Debian Technical Committee wishes to share with you what we are up to. First of all, of course, we will go over the issues that have been brought to us. But, following up from last year's presentation, we will continue presenting our ideas in how to reshape or reimagine the Technical Committee in a way it works better and is more useful for the project.

Other people: Elana Hashman Gunnar Wolf David Bremner Christoph Berg Niko Tyni Margarita Manterola Simon McVittie

What does the Technical Committee do? How can it work better for Debian? This year, we will do a short recap of our activities last year, but the main focus we want to give to this BoF is how to best move forward and reshape the Technical Committee in a way that works better, and thus is more useful for Debian.

Other people: David Bremner Elana Hashman Gunnar Wolf Simon McVittie Margarita Manterola Philip Hands Niko Tyni

Discussion about the current state of the Debian Policy Manual and related documents. Expected topics of discussion include: - where volunteer time is most needed - Q&A about the process by which Policy is modified - difficult normative bugs that are stuck and how we might unstick them - Sphinx issues: remaining bugs and infrastructure needed for translations - recruiting volunteers to translate Policy. Not strictly within the remit of Policy, but something we might discuss, is the state of the Developer's Reference, and other pieces of Debian internal documentation.

git-debrebase is a new tool for managing Debian packaging in git. dgit is a bidirectional gateway between git and the Debian archive. These tools can be used independently or in combination. We have published a tutorial for using the combination of git-debrebase and dgit to maintain Debian packages: the dgit-maint-debrebase(7) manpage. There are also: dgit-maint-gbp(7), dgit-maint-merge(7) and dgit-simple-nmu(7). In this workshop we will help package maintainers start using the workflows described in these tutorials to maintain their packages. We can also answer general questions about dgit and git-debrebase. We also hope to gain feedback as to how dgit-maint-debrebase(7), and git-debrebase and dgit more generally, could be improved. For more information about git-debrebase, see the abstract for the talk about git-debrebase. Before joining this workshop, it would be useful to review some of the dgit-maint-*(7) manpages.

Other people: Ian Jackson

With git-debrebase the Debian changes to the upstream source are represented and manipulated as git commits, with one commit corresponding to one quilt patch. However, unlike with gbp-pq and git-dpm, git-debrebase uses just a single git branch. git-debrebase branches are: * directly buildable * directly editable with git-commit(1) (whether of Debian files, upstream files, or both); * directly useable with dgit (without --quilt= option); * automatically made fast forwarding when published; and * have a history useful for git log, git blame etc. Unlike with gbp pq, there is no need to switch back and forth between public and patch queue branches and there is no need to apply and unapply patches. Unlike git-dpm, git-debrebase requires no in-tree metadata. Uploads of git-debrebase branches done with dgit publish the source both as: 1. a git branch which anyone new to Debian can immediately use, and which Debian contributors can directly work on; 2. a perfect `3.0 (quilt)' source package as expected by non-git users.

Other people: Ian Jackson

Techniques and tools for using git for Debian packaging continue to develop, though there remain many pain points. Since last year's DebConf, dgit, in particular, has seen a lot of development. The new possibilities for using this tool have not yet been fully explored. The starting point for this BoF will be a brief demo of some of elements of the pure dgit workflows that have only become possible in the past year: a merging workflow and a rebasing workflow (if `git debrebase` is not finished by DebConf, the design of this tool will be explained). A possible follow-up discussion would be figuring out what Debian package maintainers consider the highest priority pain points for maintaining Debian package in git: Should we be focusing on a new source package format? Is it documentation that is lacking? Is it our conventions regarding the BTS and NMUs that are blocking progress? Etc.

Other people: David Bremner

Going on with the Debian policy - maintainership status, incorporating changes and fixes etc

Other people: Russ Allbery