DEP14 policy for two dots

[Michael Hudson-Doyle]

Robie forgot this bit (I think):

[1]
http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/2016-November/000909.html

Cheers,
mwh

On 16 November 2016 at 05:38, Robie Basak <robie.basak at ubuntu.com> wrote:

> FTR, I answered most questions about "why not dgit?" in the thread I
> just moved to vcs-pkg-discuss only[1].
>
> For some specific questions here:
>
> On Thu, Nov 10, 2016 at 12:31:31AM +0000, Ian Jackson wrote:
> > dgit can work on Ubuntu too, in a readonly mode.  (It would be nice to
> > make `dgit push' work on Ubuntu but that requires a suitable git
> > server, and some configration on the dgit client side.)
>
> A key difference with our system is that no infrastructure is required.
> It's distributed (-able), with no special git remote.
>
> > The --skip-patches is a vital difference.
> > Has the decision to use --skip-patches been definitively taken ?
>
> For now, to fulfill our use case, yes. In the general case, no, not at
> all. Probably the best place to enter into this would be in a reply to
> my fuller explanation of the reasons in [1].
>
> > I would like to beg you to reconsider this, in the strongest possible
> > terms.  --skip-patches generates a patches-unapplied tree.
> >
> > A patches-unapplied tree:
>
> Sorry, I missed reference to this list when I wrote [1]. I'll study
> these and consider how they related to my reasons later.
>
> > If you are making patches-unapplied trees I think you cannot possibly
> > be representing the quilt patch stack of a `3.0 (quilt)' source
> > package as a series of git commits.
>
> Correct. This has not been our goal.
>
> > Representing a `3.0 (quilt)' package that way is desirable, as it
> > means that `git blame' and `git log' can be used to see which patches
> > do what.
>
> In contrast, in our Ubuntu development workflow, what you mention is not
> a requirement, but what is a requirement is to use "git blame" and "git
> log" to see when the quilt patches applied were altered. We don't want
> to drill down as far as you are suggesting; instead, we want the
> information at one level removed.
>
> Robie
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20161116/e7dab644/attachment.html>