1.0 format with direct changes in diff (Was: Debian Trends updated)

[Lucas Nussbaum <lucas@debian.org>]

Hi Bastian,

On 08/04/21 at 11:33 +0200, Bastian Blank wrote:
> Hi Lucas
> 
> On Wed, Apr 07, 2021 at 02:03:47PM +0200, Lucas Nussbaum wrote:
> > - source format 1.0 with direct changes in .diff.gz (no patch system)
> 
> For this I disagree.  At least until we have something acceptable that
> can be used in modern git workflows including operations like cherry
> picking and merge requests.

Is that a real issue in practice? If you can export the changes made to
upstream sources as a single big diff, surely you can also export them
as separate patches in 3.0 (quilt)?

I looked at whether packages with the
"direct-changes-in-diff-but-no-patch-system" lintian tag were using a
VCS, and the result is:

udd=> select vcs_type, count(*) from sources_uniq
where (source, version) in (select distinct package, package_version from lintian where tag='direct-changes-in-diff-but-no-patch-system')
and release = 'sid'
group by vcs_type;
 vcs_type | count 
----------+-------
 Bzr      |     2
 Cvs      |     1
 Git      |    67
 Svn      |     4
 (null)   |   323
(5 rows)

So the vast majority of them are also part of the set of packages that
are not maintained in a VCS.

Of the 67 maintained with Git, only half of them (32) are hosted on
salsa, and one fifth still points to alioth.  For the 28974 packages in
unstable maintained with Git, 23774 use salsa (82%) and 14% still point
to alioth. So it seems that the packages with direct changes in diff.gz
and maintained with git are generally lagging a bit more than the
average package in terms of packaging practices.

Lucas