Re: [RFC] Proposal for new source format

[Helmut Grohne <helmut@subdivi.de>]

Hi Sean,

On Sun, Oct 27, 2019 at 10:11:22AM -0700, Sean Whitton wrote:
> On Sat 26 Oct 2019 at 04:24PM -07, Russ Allbery wrote:
> > Hm, that's an interesting thought.  I do generally include that sort of
> > information in the docuemntation of all packages for which I'm upstream,
> > but for Debian I've assumed the preferred way to propose changes is the
> > BTS.  Now that's potentially changing with Salsa.  I don't really mind
> > monitoring multiple input formats, but some people will.
> 
> I think that README.source is a fine place for this sort of information.

Hell, no!

Having to read some arbitrary README.source slows down patch submission
excessively. You may consider this cost low, but if you try to file
thousands of patches across the whole archive, this adds up. Documenting
the preferred way of change submission in a machine-readable format
absolutely is a requirement for performing archive-wide changes. Our
present implementation of this requirement is "maintainers must consume
bugs filed via the BTS". I think this is less than ideal, but works
reasonably well from a submitter-pov.  Changing this to "look up in
README.source" would make me stop contributing to Debian.

I think a good way to look at this is from a user-interface pov. I'm
attaching a script "reportpatch" to this mail. It takes the path to a
.debdiff and submits the change to the package maintainer. The current
implementation parses the package and version from the patched
debian/changelog and fires up reportbug. Filing patches becomes
reasonably quick this way.

Now if a different submission is preferred (e.g. salsa pr), a new
reportpatch should detect that and create a suitable pr at a suitable
project or fall back to the bts without me having to even think about
all of this.

I caution that it is not as easy. There are two more bits that are
easily overlooked. As a patch submitter, I don't want to work from an
arbitrary VCS snapshot that may or may not work. I want a tree that
precisely reproduces the failure seen in QA. In other words, I don't
want to deal with maintainer git trees. This is sad, but required to be
effective.

After submitting the change, we all know that Debian maintainers quickly
apply it. In Debian, quickly can mean years. Consequently, I need some
identifier that allows me to mechanically check whether the requested
change was applied to unstable (or declined). Yes, this is very
different from a salsa issue being closed. The version tracking in the
BTS quite reliably answers this question.

Enough people have complained about the BTS now that I'm convinced that
we need to somehow change the process for change submission. I'm equally
convinced, that documenting it in README.source is not the solution.

Helmut

#!/usr/bin/python3

import os
import re
import sys
import unidiff

def die(message):
    sys.stderr.write("%s\n" % message)
    sys.exit(1)

c = [f for f in unidiff.PatchSet.from_filename(sys.argv[1])
     if re.match("^[^/]*/debian/changelog$", f.target_file)]
if len(c) < 1:
    die("debian/changelog not patched")
elif len(c) > 1:
    die("multiple debian/changelog??")
pkg, version = None, None
for h in c[0]:
    for l in h:
        if l.is_context:
            m = re.match(r"^([a-z0-9.+-]+) \(([^()_ ]+)\) \S+;", l.value)
            if not m:
                continue
            pkg, version = m.groups()
os.execlp("reportbug", "reportbug", "--from-buildd=%s_%s" % (pkg, version), "--tag=patch")