Re: DPMT Policy
[Barry Warsaw, 2015-10-21]
> What I'm trying to express is the team decision (a couple of debconfs ago) for
> pristine-tars rather than releasing from upstream git. I do want to keep the
> rationale in the policy doc; it's one sentence and it seems to come up often
> enough. Suggestions for better phrasing welcome!
Only version to version upstream changes should be kept in the repository -
complete upstream git history should be avoided. In order to make it
easier to cherry-pick upstream commits as patches, add remote repository
(example below).
git remote add upstream_repo git://example.com/foo.git
git fetch upstream_repo
git-dpm checkout-patched
git cherry-pick any_upstream_commit
git-dpm update-patches
> >> +for use with ``pbuilder``, ``sbuild``, etc. or as a binary package directory.
> >
> >gbp can use sbuild/pbuilder, here's my ~/.gbp.conf:
> >
> > [buildpackage]
> > builder=sbuild
>
> This is the kind of thing that should go in the wiki.
>
I simply suggest to:
s/, either as a source package for use with ``pbuilder``, ``sbuild``, etc. or as a binary package directory/ (it can be configured to use sbuild, pbuilder, etc.)/
or remove this part completely
> >> +Use the following ``git-dpm`` tag formats for the three branches named above.
> >> +Put these lines at the *end* of your ``debian/.git-dpm`` file::
> >> +
> >> + debianTag="debian/%e%v"
> >> + patchedTag="patches/%e%v"
> >> + upstreamTag="upstream/%e%u"
> >
> >I will update `py2dsp --profile dpmt ...` to do that out of the box, but
> >even then, it's better to suggest that tool in the wiki only, I guess
>
> I think so. The tag format (and IMHO the mechanism to ensure it) should go in
> policy though.
nothing against this paragraph, just wanted to state that wiki will not have
to mention it if we have a tool that configures new package the way policy wants.
> >I'm wondering about something that bit me recently: `gbp pull` instead
> >of `git pull` - should we put that into policy or is wiki warning enough?
>
> I think wiki is enough. It is possible to operate with just straight `git
> pull` because it will still fetch all commits, but when you switch to one of
> the other branches, you'll see that its head is out of date, and git will
> prompt you to pull in that branch to update it. `gbp pull` is mostly
> convenience.
gbp buildpackage will fail if you never switched to pristine-tar (and
git didn't warn you about new commits). It wasn't obvious to me why
it fails when it hit me for the first time.
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Reply to: