Thanks for your reply. Answers inline:

On Mon, Nov 6, 2017 at 8:59 AM, Guido Günther <a...@sigxcpu.org> wrote:
> Hi,
> On Tue, Oct 31, 2017 at 05:24:05PM +0100, Michael Stapelberg wrote:
>> Hi Guido,
>>
>> The pkg-go team is currently discussing changes to its workflow, and
>> we’d be interested in resolving this feature request.
>
> Can you provide a pointer to the discussion?

Have a look at 
https://lists.alioth.debian.org/pipermail/pkg-go-maintainers/Week-of-Mon-20171016/015809.html

>
>>
>> Guido Günther <a...@sigxcpu.org> writes:
>> > I would rather do this with a dfsg-clean branch. You delete once and
>> > then use git tools from there on.
>>
>> Searching for how dfsg-clean branches should be named, I found
>> https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.branch.naming.html,
>> which recommends “dfsg/latest”.
>>
>> However, my reading of section “About repacked upstream sources” of
>> http://dep.debian.net/deps/dep14/ directly contradicts the above advice:
>> DEP14 says upstream/* should contain the repackaged files.
>>
>> How do we reconcile this apparent contradiction?
>
> Since gbp makes no assumptions on this I'm happy to update the docs. How
> would we call the non-filtered branch then "nondfsg/latest"?  When we
> base our packaging on upstream git we'll likely use upstream's branch
> name but in case of tarballs we should provide a good recommendation.

Just to make sure we’re talking about the same thing: the branch
you’re asking for naming recommendations is currently called
“upstream”, yes?

If yes, then I don’t particularly like the name “nondfsg/latest”, as
it is a double-negative, but describes a very common case. Why not
keep calling it “upstream”, or “upstream/latest” if symmetry is
desired?

>
>> >> It would be great if gbp could produce the 1.2.3+dfsg tag itself by
>> >> reading debian/copyright and excluding the Files-Excluded: files.
>> >
>> > If somebody comes up with a clean patch I'm happy to merge that.
>>
>> Which part of gbp specifically should be patched here? AFAICT, there is
>> no command which pulls a new version from upstream yet. Should one be
>> added? What should it be called?
>
> My first reaction was to teach gbp import-orig to have a
>
>     gbp import-orig "git-ref"
>
> mode that would do the right thing but I now think having
>
>     gbp update "git-ref"
>
> that
>
>     - does the excluding and tagging if necessary
>     - merges to the debian branch
>
> is better. We need to make sure that gbp import-orig's filtering (using
> the --filter command line or filter= gbp.conf option) stays in sync with
> what we do so we don't have on tool using --filter= and the other one
> parsing debian/changelog.

You’re saying gbp import-orig and gbp update should both support the
same filter option, in additon to d/copyright, yes?

>
> If somebody comes up with a better name than "update" that's all fine.

“update” is a rather generic term. Given that the underlying git
operation is “git pull”, how about “gbp pull-upstream”?


-- 
Best regards,
Michael

Reply via email to