[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: proposed MBF: packages still using source format 1.0 [revised proposal]



Hi,

Based on the discussion, I propose the following:

Let's split the 626 packages in bookworm that use source format 1.0 into
three categories (1.1), (1.2), (2):
(1) packages with are very unlikely to use a VCS-based workflow (not
maintained by Debian X; not using a VCS; or referring to a broken VCS
repository; or using a VCS but not having any direct changes outside
patches)
  (1.1) Those in (1) that are key packages
  (1.2) Those in (1) that are not key packages
(2) packages which might be using a VCS-based workflow

https://udd.debian.org/cgi-bin/format10.cgi provides the list of
packages for each category. The packages count is currently:
(1.1): 53 packages
(1.2): 424 packages
(2): 149 packages

Packages in (2) need a deeper analysis to understand how VCS-based
workflows, or 3.0 (quilt), can be adapted to better support each other.
So let's not do anything about them for now, and focus on (1.1) and
(1.2).


For packages in (1.1) and (1.2), I propose to file Severity: wishlist
bugs using the following template:

------------------------------------------------------>8
Subject: please consider upgrading to 3.0 source format
Severity: wishlist
Usertags: format1.0

Dear maintainer,

This package is among the few (1.9%) that still use source format 1.0 in
bookworm.  Please upgrade it to source format 3.0, as (1) this format has many
advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2)
this contributes to standardization of packaging practices.

Please note that this is also a sign that the packaging of this software
could maybe benefit from a refresh. It might be a good opportunity to
look at other aspects as well.

This mass bug filing was discussed on debian-devel@:
https://lists.debian.org/debian-devel/2022/03/msg00074.html

Thanks

Lucas
------------------------------------------------------>8

Then, I propose that we do not discuss upgrading the severity for bugs in
(1.2) before all packages in (1.1) are fixed (or there's a good reason
not to fix the remaining ones). That way,
1/ people motivated to do the work can do it using the normal NMU
procedure (and use the bugs for coordination).
2/ nobody is forced to do work packages until the packages that we
absolutely need to fix are fixed.

I will file bugs against the 53 packages in (1.1) soon as the number is
reasonably low, and I don't think this is controversial (with wishlist
severity). I will wait a few more days before filing the bugs for
packages in (1.2).

My main motivation for filing bugs against packages in (1.2) ASAP is
that I hope that filing the bugs will trigger some maintainers to fix
their packages, if they had not realized that their packages were still
using 1.0.

Lucas


Reply to: