Hi, On Wed, Jun 15, 2022 at 04:06:55PM +0200, Lucas Nussbaum wrote: > If you look at Debian 'testing' only, I think that the only remaining > way to do that is 1.0 + quilt (packages that were using dpatch have all > been converted or removed from testing).
That's good. I wasn't able to locate a counter example. Yet, the situation is not quite what I'd like it to be. Let me pull some example: * Manually stacking patches on top of 3.0 (quilt): https://sources.debian.org/src/libreoffice/1:7.3.4%7Erc2-1/debian/rules/?hl=2048#L2048 * dpatch in unstable, but not testing: https://sources.debian.org/src/qmc/0.94-4/debian/rules/?hl=11#L3 * cdbs patchsys in unstable, but not testing: https://sources.debian.org/src/sdic/2.1.3-22.1/debian/rules/?hl=5#L5 * cdbs patchsys in testing: https://sources.debian.org/src/byacc-j/1.15-1.1/debian/rules/?hl=10#L10 https://sources.debian.org/src/phnxdeco/0.33-3.1/debian/rules/?hl=7#L7 https://sources.debian.org/src/aview/1.3.0rc1-9.1/debian/rules/?hl=20#L20 * 3.0 (quilt) with custom patch system: https://sources.debian.org/src/golang-github-rogpeppe-go-internal/1.8.1-1/debian/rules/?hl=9#L9 Also the known ones: curl, gcc, glibc Yet, it shows that quite some progress has been made on improving consistency. Thank you for that work. > According to https://udd.debian.org/~lucas/format10.cgi (which is based > on what lintian knows about the archive), there are 114 packages using > 1.0 with quilt. However, 67 of those are maintained by the Debian X > team. If you plan to discontinue 1.0+patch-system in the context of > this bug, it would probably be a good idea to have a discussion with > them to better understand their use case. Those Debian X packages at least provide internal (to the team) consistency. Their workflow is a bit unique in that upstream commits may be cherry picked directly and all other changes should use quilt patches. I'm inclined to agree that telling X people they must switch their workflow is not a useful outcome here. On the other hand, we're giving non-binding advice here and that advice is a recommendation. In any case, your argument makes 4c a more attractive option to me. Keep in mind though that the rationale given in 4c, does not really cover the Debian X workflow. So it may still be read as a recommendation for Debian X to change (or not). > I personally think that it would be enough for this bug to issue a clear > statement that we want to move away from 1.0 unless there's a good > reason, on a per-package basis, not to. That would create a mandate to > work on surveying the remaining packages and identifying the remaining > use cases. That would also allow motivated volunteers to work on > migrating the remaining packages when there's no reason to stay with > 1.0, using the NMU procedure if needed. Indeed, and I do agree that 4c is such a clear statement. I would like to see a stronger statement here, but Sam et al. tried to gain consensus on that and there wasn't. So the CTTE advice probably shouldn't override that non-consensus. That makes 4c a lot more of an attractive option to me. Finally, the main conflicting parties in this issue (oversimplified) were Lucas and Ian, so if 4c is strong enough for Lucas, that's good as well. I hereby withdraw my intention to extend the ballot as sent by Sean on June 7th. Thanks for bearing with me and bringing those arguments forward. Helmut