Merging upstream git history into the debian packaging history?

[Jonas Smedegaard]

Quoting Felipe Sateler (2013-08-29 16:24:04)
> On Thu, Aug 29, 2013 at 6:06 AM, Jonas Smedegaard <dr at jones.dk> wrote:
>> Quoting Felipe Sateler (2013-08-28 23:31:57)
>>> On Sun, Aug 25, 2013 at 6:37 PM, Jonas Smedegaard <dr at jones.dk> 
>>> wrote:
>>>>
>>>> Quoting Felipe Sateler (2013-08-26 00:09:49)
>>>>> On Sat, Aug 24, 2013 at 2:33 PM, Jonas Smedegaard <dr at jones.dk> 
>>>>> wrote:
>>>>>> Quoting Felipe Sateler (2013-08-24 18:59:03)
>>>
>>>>>>> 2. Managing patches: it looks to me like the new workflow makes 
>>>>>>> it better to make changes directly to the sources (by 
>>>>>>> cherry-picking the appropriate commits/ merging the appropriate 
>>>>>>> debian-specific branches) and setting single-debian-patch in 
>>>>>>> local-options. Has anyone tried this?
>>>>>>
>>>>>> I still favor quilt patches - and don't follow how tying our git 
>>>>>> to upstream git renders that inferior: I consider it two separate 
>>>>>> Worlds - one using git and another using tarballs and patch 
>>>>>> files.
>>>>>
>>>>> I guess I see the main benefit of the new workflow precisely that 
>>>>> the separate worlds become one. Taking a patch from upstream is as 
>>>>> simple as a cherry-pick, forwarding a patch becomes a pull request 
>>>>> of a topic branch (or committing directly, if one is also part of 
>>>>> upstream). My take is that seeing the debian package as a slightly 
>>>>> edited branch of upstream makes a lot of sense.
>>>>>
>>>>> If you accept the above premise, then the single-debian-patch 
>>>>> option seems very useful (applied in local-options, so that NMUs 
>>>>> don't break).
>>>>
>>>> Ok.  We then do not value tarballs and patches the same.
>>>
>>> I'm confused. Tarballs are preserved, and patches are still 
>>> available, although at the git repository. AFAICS, there is no data 
>>> loss in the mechanism I'm describing, am I wrong?
>>
>> By your premise, "patches" can mean an interaction with a git 
>> repository.
>>
>> I do not accept your premise, and my "patches" above implies flat 
>> files.
>>
>> Does that help resolve your confusion?
>
> Partly. The point is that I understand patches as a way of 
> communicating with upstream. If upstream uses git (a premise for the 
> current discussion to make sense), git branches/commits seem to me a 
> better communication strategy than patches as flat files. I presume 
> you value flat files for other reasons?

To me, we do not only communicate with our direct upstream, but with the 
surrounding FLOSS ecosystem.


>> I am a big fan of git.  But others are fan of other VCSes, and some 
>> still haven't seen (any of) the light(s).  So I see a relevancy of a 
>> "middle ground" using flat files and tarballs.
>
> But we are talking about integrating upstream and debian VCS, which 
> means we are all using git.

Even if both we and our direct upstream use git, our work is used (and 
usable) wider than that.  I find it a best practice to release sensibly 
structured tarballs (in addition to publishing VCS with release hints) - 
for our upstreams as well as ourselves.


>> I have recently been made aware of gbp-pq, which sounds like the 
>> right tool to me: juggle patches as git branches, but flatten 
>> sensibly (not a single huge chunk!) when "exporting" to the 
>> files-and-tarballs World. Haven't explored it yet, though - perhaps 
>> that would be interesting to you too?
>
> I tried it once, and didn't really like it. However, gbp-pq does not 
> juggle patches as git branches. Rather, it applies the patch series as 
> *one* git branch. You can then rebase and reorder it as you see fit, 
> and gbp-pq will then recreate the quilt patch series. An improvement 
> over plain quilt, but not sure if really useful (plus, you lose the 
> Nxxx naming convention, which I've grown accostumed to).

Thanks!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20130829/df69fcc6/attachment-0001.sig>