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

Re: PAPT git migration



On Thu, 01 Jun 2017 at 00:16:45 +0200, Stefano Rivera wrote:
> Hi Barry (2017.05.31_23:32:20_+0200)
> > $ gbp pq export
> > - This doesn't work until you at least do a first pq import, but now I see the
> >   d/p/changlog-docs patch gets changed in ways that lose information:
> 
> Sounds like a limitation of pq import. I'm suprised it doesn't support
> DEP3.

DEP3 describes some metadata fields, and a family of incompatible formats
(which do not necessarily seem to be designed for machine-readability) that
use those metadata fields.

gbp pq import consumes patches in `git format-patch` format. One of the
possible formats in the DEP3 family (with RFC2822-style From/Date/Subject,
unindented long description, and all non-email fields in a trailing
pseudo-header similar to common practice for Signed-off-by) is compatible
with that:

    From: ...
    Date: ...
    Subject: First line of description

    More description
    more description
    yet more description

    Bug-Debian: ...
    Applied-upstream: ...
    More-DEP3-fields-in-pseudo-header: ...
    ---
     optional diffstat here

    diff --git ...
    ...

but this style (which is a DEP3 invention, and not used outside Debian and its
derivatives) is not:

    Author: ...
    Description: First line of description
     More description
     more description
     yet more description
    Bug-Debian: ...

Converting the latter into the former seems like a valid gbp pq feature
request, but might not be practically feasible (detecting that style
mechanically so that it can be parsed is probably not trivial).

For packages that are maintained in git, either upstream or downstream,
preferring the former format makes a lot of sense IMO. Anything that relies
on round-tripping patches through git like gbp pq does is going to want
git-format-patch-compatible patches.

> So, our options are:
> 1. fix pq
> 2. modify all the patches to a format that pq understands
> 3. leave this to the maintainer to resolve (I think we expect all pq use
>    to be entirely local, so pq use isn't something we're imposing on
>    anyone)

I think it would make sense to leave the patches as-is during initial
conversion, and expect maintainers who are interested in using gbp pq
to resolve this when they import and re-export the patch series. Hopefully
a lot of current patches will become unnecessary with newer upstream
software versions, so preferring git format-patch style for new patches
might be a good "90%" solution.

    S


Reply to: