On Tuesday, January 31, 2017 02:23:29 PM Barry Warsaw wrote:
> On Jan 29, 2017, at 09:39 AM, Brian May wrote:
> >I would think "gbp pq" is the most popular.
>
> I've used it on some of my non-team packages and while it takes a little
> getting used to for the standard git-dpm workflow, it's been mostly fine.
>
> What I'd really like to see is a page like
> https://wiki.debian.org/Python/GitPackaging for a non-git-dpm workflow.
> (The page itself could probably use a bit of gardening anyway.)
> Specifically, I'd like to see guidance on any tasks which are different for
> git-pq (or non-git-dpm as the case may be).
>
> I'd suggest cloning that page instead of modify that page to cover both
> cases. Edit the clone as if it were the opinionated view of just using gbp
> tools and gbp-pq. The page should also have instructions on
> opportunistically switching away from git-dpm.
>
> Then we can start to use those instructions in anger and add any other
> recommendations for corner cases. Once we have enough experience with
> gpb-pq throughout the team, we can consider making an official switch.
We should probably be thinking in terms of post-release for this change.
During the pre-release freeze, the release team doesn't typically allow
changes that extraneous to fixing the specific issue they are letting a
package into Testing to fix. The .git-dpm file is shipped in the package, so
if we drop git-dpm, we're going to have to deal with getting .git-dpm removals
through the release team for any package that needs update during the freeze.
That will also give us time to make sure we have a proper migration strategy
and sufficient documentation.
Scott K
