Hi, First, some context with numbers: Source packages in testing: 32247 Source packages in testing using 3.0 (native): 690 (2.1%) Source packages in testing using 3.0 (quilt): 30937 (95.9%) Source packages in testing using 1.0: 620 (1.9%)
Those 620 packages probably fit in two categories: A) those whose maintainers are inactive, or unaware that the package uses 1.0, and would switch to 3.0 if they knew about it B) those whose maintainers choose to stay with 1.0 for a reason Estimating the number of packages in both categories in difficult. Packages obviously in (B) are those maintained by the Debian X team, by iwj, by tfheen, or by az. Those that provide debian/source/format are also good candidates (but there might be some false positives). The number of each case and for the combination of both are: ... with explicit debian/source/format: 178 ... maintained or co-maintained by Debian X, iwj, tfheen, az: 129 ... with explicit debian/source/format OR maintained or co-maintained by Debian X, iwj, tfheen, az: 262 (0.8%) So, we are talking about approximately 0.8% of packages here. There's a page at https://udd.debian.org/cgi-bin/format10.cgi that allows exploring the list of packages (the classification criteria are the ones used for the MBF, not the ones above). There are also graphs at https://trends.debian.net/#source-formats-and-patch-systems to see the evolution over time. On 15/03/22 at 20:08 +0100, Helmut Grohne wrote: > On Tue, Mar 15, 2022 at 04:29:17PM +0000, Ian Jackson wrote: > > (Sorry for the resend, this should have gone to the BTS the first > > time; have fixed a slip in the wording.) > > Thank you for resubmitting your issue as a bug report. > > Beyond the content of your request, I have a meta-question. Do you see a > particular urgency with the processing of your request? What is - in > your opinion - a reasonable time for resolving this? Of course, if Lucas > et al are to proceed with their deprecation work, urgency may arise in > your view, but let us assume that we can ask them to pause their > efforts for a while. > > Lucas, please pause further work on deprecating the 1.0 format in order > to give time to settle the dispute at hand. This implies not sending > further bugs about it. On the other hand, I think closing all of the > existing ones would not do any good at this time either. I do not plan to upgrade the severity of the bugs, nor to file other bugs. I am fine with maintainers/co-maintainers closing bugs (especially with a rationale), and do not plan to reopen bugs that will be closed. I do not plan to try to do further cleanup using a more complex heuristic as I think that it's valuable to use those bugs to further identify what are the blocking factors for migration to 3.0. I can agree that the heuristic to determine which packages to file bugs against could have been designed better. However, given that it's impossible to read maintainers' mind, it's probably impossible to achieve perfection here. (For example, I identified that the Debian X team was using 1.0 with a specific workflow and excluded its packages, I should probably have excluded Ian's packages as well, but only discovered the objection of other maintainers because I did the MBF.) A point that I find important is the following: as a project, I think that we care about facilitating the review of changes we make to upstream source. I think that the preferred method (and widely accepted method) for that is currently to use the 3.0 (quilt) format with DEP-3-documented patches, on top of a tarball that contains the pristine upstream source. The git packaging workflows that generate source packages using either 1.0 native packages, or 1.0 non-native packages without patches, make it harder to identify and review those changes, as they require browsing the git repository, which sometimes is not properly documented using Vcs-*. I do not think that the practice of making "fake" native source packages should be encouraged by allowing 3.0 (native) packages to have Debian revisions. So my "ideal" TC ruling on those matters would be something along the lines of: - Use of 3.0 (quilt) or 3.0 (native) is recommended - Use of 1.0 is discouraged - After a proper work to identify affected packages and notify maintainers in advance, providing a debian/source/format file can be made mandatory to accelerate the transition to 3.0 (which the ability for packages to stay with 1.0 if explicit) - Packages still using 1.0 must provide an adequate way to review Debian changes, such as a functional VCS repository. - Maintainers that rely on workflows that require the use of 1.0 are encouraged to explore how to move to 3.0 without compromising the capability to review changes using the source package. Lucas