On May 31, 2017 7:16:39 PM EDT, Simon McVittie <s...@debian.org> wrote: >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
As long as we have one team solution for this that is documented I don't care what it is as long as it works. I don't think we should have two approaches. Let's pick one and use it. Team members should not be surprised when they look at a team git repo. Scott K
