Bug#899164: ITP: opgpcard -- Create printable business cards including OpenPGP key fingerprint.
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: opgpcard Version: Upstream Author: juga URL: https://github.com/juga0/opgpcard License: GPLv3 Description: Create VCard, QR code and/or SVG printable business cards including OpenPGP key and fingerprint.
Explaining Debian's approach to QA
Over the last few months, I've found myself struggling to find a simple way to describe our approach to QA to friends and colleagues. I reached out to lamby a week or so ago and he suggested I brought it to -devel. I don't think Debian's approach to QA needs to look like that of a discrete software product or a large development consulting business or a small team of people sitting next to each other. Debian, being a universal operating system, is understood to have lots of software, lots of architectures, lots of use cases, lots of teams, etc. It does help to keep some analogies in mind, though. The three main concepts I'm struggling to convey and where I'd love this community's input are: (1) QA at Debian is a multi-stakeholder process* where ftp-master, QA, Release and other teams play a role but core accountability lies with the package maintainer, (2) The preferred vehicle for QA accountability in Debian is a bug report, and, (3) The QA "bar" is codified in Debian Policy but also in many other places (maybe not comprehensively) including for example the Release checklist I qualified "process" with an asterisk above as I'm not sure if we have documented a single QA process. It looks like there are places where Policy is enforced (e.g., ftp-master), places where testing automation is happening (e.g., lintian, piuparts, chroot/d-i runs in jenkins.d.n), campaigns (such as the recent NMUs for reproducible builds) and "final checkpoints" (e.g., release checklist) but I'm not sure if this is all mapped and documented as a single process (and, if so, if it's updated since a lot has happened in 10 years) Of course, for folks that live in a CI/CD environment where the build log and the stop light are the vehicles of accountability, the concept of a piuparts run happening after you've uploaded and getting a bug report that you then go address and "start over" is almost foreign to them. Also, that Policy codifies many sanity checks but not things that some organizations do like source code audits, etc., is also novel since many of those organizations have "single source of truth" docs that codify the "QA bar". Yet most people acknowledge Debian ships quality releases even without an approach to QA that "looks like" other use cases in the industry, so no prejudice there. Any reactions to educate me and help me formulate a more complete view would be appreciated. Thanks, bureado (not on this list) PS: it would also be interesting to analyze vs. other distros. Other distros are less universal, may or may not have highly distributed teams, may only test for a few use cases, etc., so it's clear it won't be apples to apples, but with things like OpenQA having some mindshare I think it's an interesting exercise too.
Re: Explaining Debian's approach to QA
On Mon, May 21, 2018 at 3:26 AM, Jose Miguel Parrella Romero wrote: > Over the last few months, I've found myself struggling to find a simple > way to describe our approach to QA to friends and colleagues. I reached > out to lamby a week or so ago and he suggested I brought it to -devel. The best description is that our QA is defined by the people who work on it and distributed amongst those people according to their interests, motivations and available time. This includes both people involved in Debian and external people. The wiki page provides a good overview of all the initiatives (some dead): https://wiki.debian.org/qa.debian.org Examples of the latter include Mayhem, repology and cppcheck: https://forallsecure.com/blog/ https://repology.org/repository/debian_unstable/problems http://cppcheck.sourceforge.net/devinfo/daca2-report/daca2.html There are some gaps in the wiki page too, for example helmut does a lot of cross-build QA. There are some gaps in our QA too. For example we lack an ABI tracking service using pkg-abidiff and abipkgdiff. > (1) QA at Debian is a multi-stakeholder process* where ftp-master, QA, > Release and other teams play a role but core accountability lies with > the package maintainer, This misses a few other actors; users, bug reporters, porters, NMUers, QA uploaders, stable uploaders, external researchers etc. > (2) The preferred vehicle for QA accountability in Debian is a bug > report, and, I don't think that is full picture. Many issues are only conveyed via lintian and other automated QA tools. Also sponsor or ftp-master reviews pick up lots of issues. > (3) The QA "bar" is codified in Debian Policy but also in many other > places (maybe not comprehensively) including for example the Release > checklist Indeed, there is no single document or tool that provides the full picture for a package or for Debian as a whole. This is one of the reasons I started the wiki page that lead to jwilk writing check-all-the-things. That said, tracker.debian.org aims to aggregate all available per-package data sources. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#899225: ITP: octave-level-set -- level-set toolbox for Octave
Package: wnpp Severity: wishlist Owner: Rafael Laboissière * Package name: octave-level-set Version : 0.3.0 Upstream Author : Daniel Kraft * URL : https://octave.sourceforge.io/level-set/ * License : GPL-3+ Programming Lang: C++, Octave Description : level-set toolbox for Octave This package contains routines for calculating the time-evolution of the level-set equation and extracting geometric information from the level-set function in Octave, a scientific computation software. This Octave add-on package is part of the Octave-Forge project. This package will be maintained in the realm of the Debian Octave Group. A preliminary version of the package can be built using git-buildpackage from the repository https://salsa.debian.org/pkg-octave-team/octave-level-set.git
