Sean Whitton wrote on Fri, Jan 20, 2017 at 14:32:16 -0700:
> On Fri, Jan 20, 2017 at 12:21:56AM +0000, Ian Jackson wrote:
> > 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.
>
> +1 from me.
>
> On Fri, Jan 20, 2017 at 03:52:09PM +0000, Daniel Shahaf wrote:
> > 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").
>
> I prefer the active voice because this is a tutorial manpage (and the
> rest of the manpage already uses the active voice).
+1 to internal consistency.
> > 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.
>
> One of the reasons for using the dgit-maint-merge workflow is to make it
> simpler and easier to review, upstream and drop individual changes.
> This bug is about noting the cases in which the workflow can make it
> harder to do those things. However, your text might suggest that
> dgit-maint-merge(7) makes those things harder in general, and I'm very
> keen to avoid that mistaken impression. So I would prefer to stick with
> Ian's text.
Of course I'm not trying to cause a mistaken impression. However, as
Ian noted, in a merge workflow merge conflict resolutions are not
represented in the history as first-class objects, which means that some
operations on "individual logical changes that comprise the delta" are
harder in that workflow than in others. For example, the merge workflow
has no equivalent of 'git log debian/patches/01_foo.patch'.
To be clear, I'm not trying to open a holy war here; I'm just stating
what I think is an objective criticism of that workflow. I suppose you
might not agree with the last paragraph entirely, and that's fine; I'd
be happy to go with whatever text Ian chooses.
Cheers,
Daniel
