Re: git-dpm (was Re: Bug#729956: Forwarded upstream)
On Thu, Sep 07 2017, Brian May wrote: > In general, however, when something does go badly wrong I think it will be a > lot easier to diagnose, understand, and fix with GPB PQ then with git-dpm. > git-dpm can get very messy very quickly, particularly if you forget to pull > before making changes (personally I make this mistake too frequently) or > update > to a new upstream version without using the correct git-dpm workflow - I have > seen both of these situations happen. I concur. gbp is not without issues, but as you said, gbp is easier to reason about and fix. I don't use gbp daily. In fact, I maintain or edit existing packages not as frequently as I would like, often having to re-read the documentation along the way. The fact that gbp is better documented is a big plus, even if everything else would be equal. Simplicity goes a long way for cooperative maintenance. I'm relieved gbp is now the recommended choice.
Re: git-dpm (was Re: Bug#729956: Forwarded upstream)
On 2017-09-07 14:54, Scott Kitterman wrote: > It's a wiki. The resolution of your annoyance is within your grasp. I had already fixed it. Sorry if I didn't make this clear.
Re: git-dpm (was Re: Bug#729956: Forwarded upstream)
On Thursday, September 07, 2017 09:28:11 AM Brian May wrote: > On 2017-09-07 08:42, Scott Kitterman wrote: > > Conveniently, we already decided to switch: > > > > https://wiki.debian.org/Python/GitPackagingPQ > > It was annoying me that these instructions were missing the last steps > on how to switch the default branch to debian/master and delete the old > branch. > > These steps are very important to: > > (a) prevent confusion on which branch to use. > (b) prevent confusion on qa.debian.org, which uses the default branch to > check that the git version. > > === cut === > > ssh git.debian.org > cd "/git/python-modules/packages/$1.git" > git symbolic-ref HEAD refs/heads/debian/master > exit > > cd "$TMP" > git push origin :master > > === cut === > > I also have a script to automate the entire conversion, and assuming the > git repository is up-to-date and nobody is withholding pushes, it seems > to work well. > > /srv/home/users/bam/convert on git.debian.org I know this is excessively snarky, but it's the best I can manage late at night: It's a wiki. The resolution of your annoyance is within your grasp. Scott K
Re: git-dpm (was Re: Bug#729956: Forwarded upstream)
On 2017-09-07 08:42, Scott Kitterman wrote: > Conveniently, we already decided to switch: > > https://wiki.debian.org/Python/GitPackagingPQ It was annoying me that these instructions were missing the last steps on how to switch the default branch to debian/master and delete the old branch. These steps are very important to: (a) prevent confusion on which branch to use. (b) prevent confusion on qa.debian.org, which uses the default branch to check that the git version. === cut === ssh git.debian.org cd "/git/python-modules/packages/$1.git" git symbolic-ref HEAD refs/heads/debian/master exit cd "$TMP" git push origin :master === cut === I also have a script to automate the entire conversion, and assuming the git repository is up-to-date and nobody is withholding pushes, it seems to work well. /srv/home/users/bam/convert on git.debian.org
Re: git-dpm (was Re: Bug#729956: Forwarded upstream)
On 2017-09-07 08:42, Scott Kitterman wrote: > Conveniently, we already decided to switch: > > https://wiki.debian.org/Python/GitPackagingPQ Worth noting, while there are some big gotchas with git-dpm, there are also some big gotchas with GPB PQ. GPB PQ isn't a magical solution that will solve all our problems. e.g. forgetting to import the PQ (if not already done) *before* updating to a new upstream version. Or forgetting to import the PQ after a git pull makes modifications to the upstream patch files. In general, however, when something does go badly wrong I think it will be a lot easier to diagnose, understand, and fix with GPB PQ then with git-dpm. git-dpm can get very messy very quickly, particularly if you forget to pull before making changes (personally I make this mistake too frequently) or update to a new upstream version without using the correct git-dpm workflow - I have seen both of these situations happen.
Re: git-dpm (was Re: Bug#729956: Forwarded upstream)
On September 6, 2017 5:16:13 PM EDT, Yuri D'Elia wrote: >On Wed, Sep 06 2017, Andreas Tille wrote: >>> But just to confirm, I see that statsmodels is just using >>> git-buildpackage? >> >> Yes. > >Ok, that's reassuring. I'll have a look at the packaging, since I'm >already on alioth. > >But since DPMT is CC-ed (I normally follow via gmane), I take the >occasion to say that I _really_ _REALLY_ wished the recommendation on >git-dpm to be reconsidered, or at least relaxed. > >For a newcomer, git-dpm is overkill and underdocumented. >>From an outsider, making a Debian package already looks daunting. >git-dpm does not help. > >On the other hand, git-buildpackage is a relatively smooth progression >from quilt, and it does provide some added convenience. Conveniently, we already decided to switch: https://wiki.debian.org/Python/GitPackagingPQ Scott K
git-dpm (was Re: Bug#729956: Forwarded upstream)
On Wed, Sep 06 2017, Andreas Tille wrote: >> But just to confirm, I see that statsmodels is just using >> git-buildpackage? > > Yes. Ok, that's reassuring. I'll have a look at the packaging, since I'm already on alioth. But since DPMT is CC-ed (I normally follow via gmane), I take the occasion to say that I _really_ _REALLY_ wished the recommendation on git-dpm to be reconsidered, or at least relaxed. For a newcomer, git-dpm is overkill and underdocumented. >From an outsider, making a Debian package already looks daunting. git-dpm does not help. On the other hand, git-buildpackage is a relatively smooth progression from quilt, and it does provide some added convenience.
