Ian Jackson wrote on Fri, Jan 20, 2017 at 00:21:56 +0000:
> Let me quote yur preferred wording from your patch. (I find it easier
> to deal with this inline as prose than as an attachment. And I'd like
> Daniel's opinion, as someone who has to deal with "not their own"
> packages, before concluding that we have the wording right.)
I think in my case, the root problem was that the assumptions of
dgit-maint-merge(7) did not hold: I was using the source package
not as an "output format" but as a the primary source.
> Sean Whitton:
> > +This workflow is less suitable for some packages. When the Debian
> > +delta is very complex, with large parts not expected to ever be merged
> > +upstream, it might be preferable to maintain the delta as a rebasing
> > +patch series. If this applies to your package, consider
> > +dgit-maint-gbp(7), and see Debian bug #720177.
>
> This is good text but it's a little weaker than I would prefer.
> Lack of a coherent patch stack is a problem if the individual patches
> are hard to extract from the history, which occurs when the patches
> need adjustment or conflict resolution to conform to new upstreams, or
> cannot be easily separated.
>
Good point.
> And I think the point about not merging upstream cuts both ways.
> Things that _are_ expected to go upstream may need to be distinguished
> from ones which don't. The key question is whether the patches need
> to be maintained as a downstream delta for any time.
>
> How about:
>
> This workflow is less suitable for some packages. When the Debian
> delta contains multiple pieces which interact, or which you aren't
> going to be able to upstream soon, it might be preferable to
> maintain the delta as a rebasing patch series.
Content-wise, this seems good to me: it covers both the "represent
independent changes" point and the "merge conflicts" point now added.
I do have a few editorial changes to suggest:
1. Change you aren't going to..." to passive voice ("aren't going to be
upstreamed soon").
2. Maybe state the rationales explicitly, at least in a half sentence?
Warnings tend to have better retention when accompanied by rationales.
So:
This workflow is less suitable for some packages. When the Debian
delta contains multiple logical changes, it might be preferable to
maintain the delta as a rebasing patch series, in order to
facilitate reviewing/upstreaming/dropping individual changes.
And thanks again, Ian, for the great response on (and off) IRC, and
apologies again for my initial misunderstanding of the problem.
(I hadn't realized that dgit supported multiple workflows.)
Cheers,
Daniel
