Quoting Felipe Sateler (2013-08-29 16:24:04) > On Thu, Aug 29, 2013 at 6:06 AM, Jonas Smedegaard <d...@jones.dk> wrote: >> Quoting Felipe Sateler (2013-08-28 23:31:57) >>> On Sun, Aug 25, 2013 at 6:37 PM, Jonas Smedegaard <d...@jones.dk> >>> wrote: >>>> >>>> Quoting Felipe Sateler (2013-08-26 00:09:49) >>>>> On Sat, Aug 24, 2013 at 2:33 PM, Jonas Smedegaard <d...@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
signature.asc
Description: signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
