Re: git-dpm vs gbp-pq: new upstream and patch refresh (long)
On Sep 05, 2014, at 01:21 PM, Simon McVittie wrote:
>It might also be worth noting that the systemd maintainers switched from
>git-dpm to gbp-pq recently (between 204 and 208, I think), so they
>obviously didn't think git-dpm was the better option.
Are there any artifacts of this switch, e.g. mailing list archives, wiki
pages, etc.? I'd love to read some background on why they switched.
>The systemd package is an interesting stress-test for patch systems,
>because:
>
>* upstream don't do formal micro releases (there is no v208.1 and
> probably never will be) but they do cherry-pick a lot of bugfixes to
> a stable-branch (e.g. v208-stable), so the Debian maintainers apply
> patches from the upstream v208-stable branch in bulk;
>
>* the Debian maintainers also apply a significant number of local
> patches to preserve historical functionality of Debian's udev and
> sysvinit, some of which are never going to go upstream
>
>so managing its patch-set is non-trivial. This might mean that the right
>decision for systemd is not the same as the right decision as for a
>package that will hopefully only have a couple of Debian patches; I
>don't know.
I think the overwhelming majority of our packages come from tarballs released
on PyPI, so we'll have a fairly regular workflow. Ignoring outliers[*], I
think we generally won't have tons of cherry picked patches in our packages,
and hopefully no need for tons of local deviation, in the common cases. This
is also why I feel strongly that we should usually use a pristine-tar branch.
Whatever regime and workflow we pick, let's optimize for the common,
i.e. PyPI-published case.
Cheers,
-Barry
[*] A policy we discussed at DC14 was to allow for deviation from team policy
in special cases, but only if the reason and differing workflow was documented
in d/README.source. So whatever we choose, we acknowledge that some packages
need special handling.
Reply to: