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? > > 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. > > 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). -- Saludos, Felipe Sateler _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
