git-packaging workflows

[Felipe Sateler]

On Sat, Aug 23, 2014 at 9:53 AM, Reinhard Tartler <siretart at gmail.com> wrote:
> 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)

Yes, that is indeed required.

> 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.

Doesn't gbp have an option to autoguess the upstream vcs tag?

>
>>
>> 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

I think I will adopt this scheme for some of my packages. However, I
will wait until this is resolved (I don't have time to look into
this). Perhaps we can filter commits that touch the debian/ dir?

Also, I'll start experimenting with the patch-queue feature of gbp.


Thanks to all for your responses

-- 

Saludos,
Felipe Sateler