Hi. Almost two weeks ago [1] I started a discussion on whether we wanted to increase the strength of our recommendation of the dh sequencer from debhelper. This message is a consensus call summarizing my reading of the discussion.
[1] https://lists.debian.org/msgid-search/tsla7fqjzyv....@suchdamage.org My approach for calling consensus is heavily influenced by RFC 7282 [2], which talks about some approaches for evaluating rough consensus within the IETF. That document is not normative policy there and certainly has no force here, but the authors have spent a lot of time thinking about how to understand what an opinionated group of technologists mean when writing to a mailing list. In judging consensus, it's much more about whether issues have been considered and whether the community believes the issues have been adequately resolved than numbers of people on any side of a given issue. [2] https://tools.ietf.org/html/rfc7282 Please send any comments by 2019-06-16. Please distinguish cases where you believe I've misread the discussion from new contributions intended to change the community's view. At the core of this discussion are a number of key issues that were reflected in comments throughout the discussion. * People who make changes across the archive such as enabling hardening, cross-building, bootstrapping, etc benefit significantly from more uniformity in packaging practices. The time they spend working on packages that use dh is significantly less. That is, people working on making Debian more reproducible benefit from when we adopt more uniform practices. * People who spend time fixing the archive, fixing RC bugs, etc don't like to see churn in areas that are already working. If it's working well, don't break it. Developers doing NMUs do not always perform adequate QA of their changes. * Traditionally we've valued respecting the maintainer's preference above most other factors. In the limit, short of orphaning packages or removing maintainers, we don't actually have tools to get maintainers to do things they don't want to. Per our constitution no one in Debian is obligated to do anything besides not stand in the way of others. And yet this discussion is about pushing things towards uniformity and in a small way away from maintainer preference. Recommendation ============== There are some exceptions where we think using dh is the wrong choice; see below. We have a strong consensus that other than in exceptional circumstances, new packages should use dh. There's a weaker consensus that existing packages should use dh, but migrating working packages to use dh is often not the best use of our resources and can be harmful when it introduces bugs. A number of people spoke against choosing dh for existing packages. I looked at the reasons expressed. A number of these focused on concerns about introducing bugs. When I read through all the messages I think it was fair to interpret a lot of these concerns as asking us to be careful about how we spend our resources. It is generally harmful to convert a package to dh without adequate testing. It often makes sense to spend time on something other than converting working packages to dh unless doing so fixes something else or makes something easier. But if a maintainer asks if in an ideal world should their package use dh, the rough consensus of this discussion is that other than exceptional circumstances, "yes". Exceptional Circumstances ========================= This is not a complete list of reasons not to use dh. That list will likely evolve over time, but here are reasons identified in the discussion. * If you're actively working on something new, innovation is still something we care about. We're not trying to close down development of the next great thing. * Cdbs has a few features that dh doesn't have. The Haskell tools in cdbs ar critical to our current Haskell infrastructure. Cdbs flavors don't seem to have a dh analogue. For examples compare https://salsa.debian.org/multimedia-team/snd/blob/master/debian/rules to https://salsa.debian.org/multimedia-team/soundscaperenderer/blob/master/debia n/rules . If cdbs is doing something for you, then it probably makes sense to stay with it for now. But it sounds like there's discussion of retiring cdbs longterm. So if you're using cdbs for things dh is perfectly good at, the cdbs exception is much weaker and possibly may not apply. * Consistency with teams. If your team is using something else, then it might be worth having a discussion within the team about whether that's still the best choice, but consistency within teams is important. * We need to go back and check if there are any bootstrapping concerns that should affect build system decisions for specific packages. There was strong consensus that we should have a lintian tag that can be overridden to indicate why a package is not using debhelper. I think there is rough consensus (although rougher than some other things) that individual maintainer preference is not in and of itself a justification for not using dh. That is, I think the people arguing for how using dh made their jobs either in making large changes to Debian made a better case than those arguing for maintainer preference. However Mo Zhou reminded us that we need to keep things fun. If a maintainer really wants to use something other than dh there's a good chance that there is some underlying requirement dh is not meeting. And that probably is a legitimate exception. we're not coming after people with pitchforks if they don't use dh. It might simply mean their packages have a bug. It certainly doesn't mean they are obligated to fix that bug, although best practice in our community is to work with submitters of patches to review those patches. Is Not Using DH a Bug? ====================== It's certainly not an RC bug. There was some talk of it eventually being an RC bug if a new package doesn't use DH (and doesn't fall under an exception). I don't think there's consensus for that today. It's obviously not a bug if one of the exceptions applies, but once the lintian tag exists, overriding that tag sounds to me like best practice to document the exception. (Presumably for things like Haskell we'd want Lintian to be smart enough to figure that out on its own) To some extent I'm extrapolating from implications of the rest of the consensus call for the rest of this section. There was some discussion of whether not using dh should be a normal bug, but the comments about that were inconsistent with the rest of the discussion. But if the consensus call above that existing packages (absent exceptional circumstances) should use dh stands, that's approximately the definition of a normal bug. So my reading is that absent exceptional circumstances, not using dh is a normal severity bug. It doesn't mean you should file that bug and it doesn't mean that you should go fix that bug. We definitely didn't get the kind of support we'd be needing for a mass bug filing or anything like that. It wouldn't serve a point. This isn't atypical. There are a lot of things lintian flags that are technically bugs, but we wouldn't want to mass file all lintian tags (even if we could filter out false positives) as bugs. This paragraph is very much my interpretation. I'd personally say that if you're going to file a bug that a particular package doesn't use dh, have a good reason and document it in that bug. Your reason might be "I want to contribute; I'm willing to dedicate time and updating the packaging would make it much more appealing to work on." Often your reason will be that there's some other problem, migrating to dh will fix that problem, and between the time you're willing to spend and the time you hope the maintainer will spend it's worth doing a good job of that migration. My interpretation of our standard practices is that maintainers have wide discretion in which bugs they work on. That said, if someone submits a patch, it's good if you review it. It's fine to ask them to do the necessary testing work and it's fine to hold them to the same high standards that you hold yourself to. If they are less experienced with the package it might make sense for them to do tests that make up for that experience gap. None of this changes any of that or asks maintainers to treat bugs about dh differently than other bugs. Best Practices for Testing DH Conversions ========================================= * Run a debdiff of the binaries to see what has changed * Use diffoscope * Run autopkgtests * Test piuparts Generally look at the packaging and explain any changes carefully. So I should Go NMU the Archive to DH ==================================== ABSOLUTELY NOT! We had a long discussion of NMUs and dh that was probably my fault and unnecessary. Through a round about set of messages we seemed to come to a consensus that is roughly the same as our existing NMU policy. I don't see a consensus to change how NMUs regarding dh are handled. Generally doing an NMU to change packaging style is not a good idea. There are cases where it might be appropriate. Feel free to read the longer discussion and to look at discussions of NMUs in Developer's Reference. Why are We Doing this ===================== https://lists.debian.org/msgid-search/20190513173542.ga24...@espresso.pseudorandom.co.uk is fairly typical of this. There was also some discussion in the initial message.
signature.asc
Description: PGP signature
