git-packaging workflows

[Reinhard Tartler]

On Fri, Aug 22, 2014 at 11:08 AM, Felipe Sateler <fsateler at debian.org> wrote:
> Resurrecting an old thread
>
> On Sat, Apr 6, 2013 at 4:32 AM, Reinhard Tartler <siretart at gmail.com> wrote:
>> Hi,
>>
>> Recently, Russ' blog post was echoed on http://planet.debian.org:
>>
>> http://www.eyrie.org/~eagle/journal/2013-04/001.html
>>
>> In that post, he describes how to combine both the "import tarball"
>> and the "have upstream history" available in the upstream packaging
>> branch. AFAIUI, the heavy work is implemented in git-buildpackage's
>> --upstream-vcs-tag <tag> option.
>>
>> While that option is news to me, I wonder if maybe anyone else already
>> experiments with this? Does the team feel that making it mandatory for
>> our package would be beneficial and appropriate?
>
> I know some in the team have experimented with this new workflow.
> Could you share your experiences with it? I'm thinking that we should
> encourage this workflow a bit more: it makes collaboration with
> upstream easier (in both directions). However I'm still not too clear
> on what would it look like, so I'd like to hear from people that have
> been using it about their thoughts.

I've been using that for libav, and am comfortable with it. The
caveats that I've found so far:

1. you need to manually add a named remote (git remote add upstream
«upstream_git_url» && git remote update upstream)
2. you need to identify the upstream tag and must not forget to pass
it to git-import-orig --upstream-vcs-tag

The first one could be scripted, I guess.

>
> Questions of interest: are you using gbp pq? If not, how do you pick
> patches from upstream? How do you post patches back to upstream?
>
> I do think we need to somehow restrict the commits that get posted on
> the commit list. Sometimes we get a mailbomb of new commits... :p

Yes, that's the third caveat. I promised at some point to have a look
at the mail hook, but didn't find the time. Sorry

Best,
Reinhard