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
