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
