Hi. Last month[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 describing how I as the discussion facilitator see the project consensus. After the original discussion, I published the first version of this consensus call on May 25. Comments were due by June 16. [1] https://lists.debian.org/msgid-search/tsla7fqjzyv.fsf@suchdamage.org 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 unless there is some reasonable reason to do something else, 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 unless there is an adequately justify reason to do something else, "yes". After the initial consensus call, a few people raised additional concerns about this recommendation. No new issues were raised; the points raised during final comments had been adequately addressed during the body of the discussion. The comments were not numerous enough to make me think I had misjudged the community's values when considering the various trade offs. In addition, there were also new comments in support of more uniformity in packaging. Reasons to Do Something Else ============================ 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. See my next steps at the end of this message. 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 reason not to use dh. 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. Again there were some dissenting final comments, but my reading is the consensus stands. 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 there is a reasonable reason not to use dh, 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 adequate justification) should use dh stands, that's approximately the definition of a normal bug. So my reading is that absent adequate justification, 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. Next step for this section is to have a policy discussion; see below. 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. Next Steps ========== I will go open a bug on debian-policy asking the policy editors to document this consensus following their standard process as the debian-policy lists sees best. Some early discussions with the policy editors suggest they have ideas and are well up to the challenge of proposing something for the community to consider. Thanks Russ and Sean! I'll see whether the Lintian maintainers need a bug filed and file one if necessary. I'll make sure that people involved in bootstrapping have an opportunity to comment in the policy discussion if they have input. A Closing Word from Our Sponsors ================================ Thanks everyone for helping out with a great discussion. I hope that we can use this approach for exploring other issues and reach similarly productive outcomes. While I'm writing to -devel-announce, I could use your help with another matter. In preparation for a meeting with the Antiharassment team, account managers, former DPL and myself, I am soliciting feedback on how well the Antiharassment team is meeting the project's needs. I've received very little feedback from people who have actually interacted with our antiharassment team either as reporters or respondents. I regret sticking something this ephemeral onto a long-lived message, but I'd regret a second post to debian-devel-announce more. I could really use your feedback; see https://lists.debian.org/msgid-search/tslmuivstkr.fsf@suchdamage.org for my questions. Thanks, Sam Hartman Debian Project Leader
Attachment:
signature.asc
Description: PGP signature