Re: git-packaging workflows
On Sat, Aug 23, 2014 at 9:53 AM, Reinhard Tartler siret...@gmail.com wrote: On Fri, Aug 22, 2014 at 11:08 AM, Felipe Sateler fsate...@debian.org wrote: Resurrecting an old thread On Sat, Apr 6, 2013 at 4:32 AM, Reinhard Tartler siret...@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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: git-packaging workflows
On Fri, Aug 22, 2014 at 11:08 AM, Felipe Sateler fsate...@debian.org wrote: Resurrecting an old thread On Sat, Apr 6, 2013 at 4:32 AM, Reinhard Tartler siret...@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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: git-packaging workflows
Resurrecting an old thread On Sat, Apr 6, 2013 at 4:32 AM, Reinhard Tartler siret...@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. 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 -- 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
Re: git-packaging workflows
On 2014-08-22 11:08:17, Felipe Sateler wrote: Resurrecting an old thread On Sat, Apr 6, 2013 at 4:32 AM, Reinhard Tartler siret...@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. 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'm not a great fan of the toolchain around packages in git. I like to store packages and git and also enjoy the default git-import-orig (with pristine-tar) layout, but that's about the only command I use from git-buildpackage besides tagging the Debian revision and exporting the orig tarball. All the other tools just couldn't convince me. Most of the time I write patches directly against the upstream repository and forward them from there. And if I take patches from the upstream repository, I export them from there, apply them to the package and do the quilt refresh dance if necessary. Cheers -- Sebastian Ramacher signature.asc Description: Digital 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
Re: git-packaging workflows
On Wed, Apr 17, 2013 at 3:27 AM, Hans-Christoph Steiner h...@at.or.at wrote: On 04/06/2013 03:32 AM, Reinhard Tartler 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? It sounds very promising, but I think its too soon to mandate it. I think people should all try it and then report back on experience with it. If no one hits major hurdles, then mandate it. I'm going to try my first package in this style: http://anonscm.debian.org/gitweb/?p=collab-maint/python-qrcode.git I've implemented this on rtmpdump: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/rtmpdump.git In order to implement it, I had to use the debian/get-git-source.sh script, which I have simplified a bit on this occasion. After that, this approach basically just requires passing the --upstream-vcs to git-import-orig, which I could point to FETCH_HEAD (rtmpdump upstream does not seem to believe in neither releases nor tags). Comments welcome. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: git-packaging workflows
On 04/06/2013 03:32 AM, Reinhard Tartler 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? It sounds very promising, but I think its too soon to mandate it. I think people should all try it and then report back on experience with it. If no one hits major hurdles, then mandate it. I'm going to try my first package in this style: http://anonscm.debian.org/gitweb/?p=collab-maint/python-qrcode.git .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: git-packaging workflows
Quoting Felipe Sateler (2013-04-08 06:56:51) On Sun, Apr 7, 2013 at 8:15 AM, Jonas Smedegaard d...@jones.dk wrote: Quoting Reinhard Tartler (2013-04-06 09:32:04) 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 have (way more complex) practiced that for a few years for Sugar packages. Now that it has become dead simply to do with git-buildpackage I wholeheartedly welcome mandating it - but only for those of our upstreams that themselves use git, obviously. I suppose fixing the history would be too time consuming? So the history would remain as imported tarballs? Not sure what you mean, Felipe. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: git-packaging workflows
On Mon, Apr 8, 2013 at 7:07 AM, Jonas Smedegaard d...@jones.dk wrote: Quoting Felipe Sateler (2013-04-08 06:56:51) On Sun, Apr 7, 2013 at 8:15 AM, Jonas Smedegaard d...@jones.dk wrote: Quoting Reinhard Tartler (2013-04-06 09:32:04) 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 have (way more complex) practiced that for a few years for Sugar packages. Now that it has become dead simply to do with git-buildpackage I wholeheartedly welcome mandating it - but only for those of our upstreams that themselves use git, obviously. I suppose fixing the history would be too time consuming? So the history would remain as imported tarballs? Not sure what you mean, Felipe. I'm referring to how a transition to the new system would be made. Would we want to rewrite history to track the upstream repository in past releases? Or do we treat it as water under the bridge and just attach the upstream history for newer releases? -- 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
Re: git-packaging workflows
On Mon, Apr 8, 2013 at 2:43 PM, Felipe Sateler fsate...@debian.org wrote: On Mon, Apr 8, 2013 at 7:07 AM, Jonas Smedegaard d...@jones.dk wrote: Quoting Felipe Sateler (2013-04-08 06:56:51) On Sun, Apr 7, 2013 at 8:15 AM, Jonas Smedegaard d...@jones.dk wrote: Quoting Reinhard Tartler (2013-04-06 09:32:04) 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 have (way more complex) practiced that for a few years for Sugar packages. Now that it has become dead simply to do with git-buildpackage I wholeheartedly welcome mandating it - but only for those of our upstreams that themselves use git, obviously. I suppose fixing the history would be too time consuming? So the history would remain as imported tarballs? Not sure what you mean, Felipe. I'm referring to how a transition to the new system would be made. Would we want to rewrite history to track the upstream repository in past releases? Or do we treat it as water under the bridge and just attach the upstream history for newer releases? I think that the latter would be sufficient. First, not all of our upstreams do have a git. Second, breaking the working git clones of all team members is hardly worth it IMO. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: git-packaging workflows
Quoting Reinhard Tartler (2013-04-06 09:32:04) 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 have (way more complex) practiced that for a few years for Sugar packages. Now that it has become dead simply to do with git-buildpackage I wholeheartedly welcome mandating it - but only for those of our upstreams that themselves use git, obviously. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: git-packaging workflows
On Sun, Apr 7, 2013 at 8:15 AM, Jonas Smedegaard d...@jones.dk wrote: Quoting Reinhard Tartler (2013-04-06 09:32:04) 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 have (way more complex) practiced that for a few years for Sugar packages. Now that it has become dead simply to do with git-buildpackage I wholeheartedly welcome mandating it - but only for those of our upstreams that themselves use git, obviously. I suppose fixing the history would be too time consuming? So the history would remain as imported tarballs? -- 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
git-packaging workflows
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? -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
