Path: csiph.com!usenet.pasdenom.info!aioe.org!bofh.it!news.nic.it!robomod
From: Scott Kitterman <debian@kitterman.com>
Newsgroups: linux.debian.maint.python
Subject: Re: PAPT git migration
Date: Thu, 01 Jun 2017 05:10:02 +0200
Message-ID: <tNoEO-5s8-15@gated-at.bofh.it>
References: <tNh0B-4U-7@gated-at.bofh.it> <tNjvr-20L-1@gated-at.bofh.it> <tNk89-2vg-7@gated-at.bofh.it> <tNl4d-34b-5@gated-at.bofh.it>
Old-Return-Path: <debian@kitterman.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Approved: robomod@news.nic.it
Lines: 91
Organization: linux.* mail to news gateway
Sender: robomod@news.nic.it
Xref: csiph.com linux.debian.maint.python:9543



On May 31, 2017 7:16:39 PM EDT, Simon McVittie <smcv@debian=2Eorg> wrote:
>On Thu, 01 Jun 2017 at 00:16:45 +0200, Stefano Rivera wrote:
>> Hi Barry (2017=2E05=2E31_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:
>>=20
>> Sounds like a limitation of pq import=2E I'm suprised it doesn't
>support
>> DEP3=2E
>
>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=2E
>
>gbp pq import consumes patches in `git format-patch` format=2E 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: =2E=2E=2E
>    Date: =2E=2E=2E
>    Subject: First line of description
>
>    More description
>    more description
>    yet more description
>
>    Bug-Debian: =2E=2E=2E
>    Applied-upstream: =2E=2E=2E
>    More-DEP3-fields-in-pseudo-header: =2E=2E=2E
>    ---
>     optional diffstat here
>
>    diff --git =2E=2E=2E
>    =2E=2E=2E
>
>but this style (which is a DEP3 invention, and not used outside Debian
>and its
>derivatives) is not:
>
>    Author: =2E=2E=2E
>    Description: First line of description
>     More description
>     more description
>     yet more description
>    Bug-Debian: =2E=2E=2E
>
>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)=2E
>
>For packages that are maintained in git, either upstream or downstream,
>preferring the former format makes a lot of sense IMO=2E Anything that
>relies
>on round-tripping patches through git like gbp pq does is going to want
>git-format-patch-compatible patches=2E
>
>> So, our options are:
>> 1=2E fix pq
>> 2=2E modify all the patches to a format that pq understands
>> 3=2E 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=2E
>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=2E
>
>    S

As long as we have one team solution for this that is documented I don't c=
are what it is as long as it works=2E I don't think we should have two appr=
oaches=2E  Let's pick one and use it=2E  Team members should not be surpris=
ed when they look at a team git repo=2E

Scott K