Sean Whitton writes ("Re: Bug#840153: Feedback, and dgit-maint-gbp(7)"):
> I should say that there are some commits on my branch that I didn't
> explicitly suggest cherry-picking in my previous e-mail. Most of them I
> added after sending that e-mail. Apologies if that's inconvenient.
Oh! Would you care to separate out the ones you would like me to
take, into their own (sub) branch ?
> On Sat, Oct 29, 2016 at 05:12:42PM +0100, Ian Jackson wrote:
> > I think dgit in split brain mode will insist on making a new
> > maintainer view tag. But I think it might be OK to reuse but re-sign
> > an existing maintainer view tag. The dgit server won't accept the
> > maintainer view tag if it's not signed by a DD (or appropriate DM),
> > and in that case would reject the whole push.
>
> As I understand it, re-signing a tag is as good as making a new tag,
> albeit with the same name. So the sponsor would have to ask the sponsee
> to delete their tag and pull from dgit-repos, which can get confusing.
Yes.
> How about adding advice to the sponsor, saying
>
> "if your sponsee has added a tag, ask them to delete it from their
> repo /before/ you upload, as part of the review process. This
> avoids confusion and difficulties later"
I wonder if it would be better practice for the sponsor to make the
tag and finalise the changelog. With dgit, changes made by the
sponsor are easily picked up by the sponsee.
> > So I am going to make dgit quilt-fixup have an option to explictly
> > save the generateed dgit view.
>
> Okay. Let me know when these are done and I can take another look at the
> manpage.
Willdo.
> > How does gbp tell the difference between a patches-applied and
> > patches-unapplied branch ?
>
> I don't think it needs to. It relies on dpkg-buildpackage applying or
> unapplying the patches. In the e-mail I recall seeing from the gbp
> maintainer, he suggested using d/source/local-options. I'm not sure if
> the options that were required are all permitted in d/source/options.
It is in impossible to reliably tell the difference between a
patches-applied and a patches-unapplied tree. If dpkgs-source is
doing that it is not reliable.
Consider the following edge case:
$ dgit clone foo
[ observe that actually the bug is being generated by the sole
Debian patch ]
* git revert [that sole Dbian patch]
* [ edit changelog ]
This tree is a valid patches-unapplied tree. But the user's intent is
that it's a patches-unapplied tree.
Sean Whitton writes ("Re: Bug#840153: Feedback, and dgit-maint-gbp(7)"):
> On Sat, Oct 29, 2016 at 05:12:42PM +0100, Ian Jackson wrote:
> > Well, the workflow as presented doesn't do anything to produce either
> > a new .orig or a git tree which contains appropriate information. And
> > what exactly that git tree's history should look like depends on the
> > maintainer's workflow. The part of the presented workflow that
> > updates debian/patches/* is implicit in dgit -wgf push.
>
> I missed replying to this.
>
> If you merged an upstream version and generated a corresponding
> orig.tar, how could this be disruptive to the maintainer? Is that issue
> that dgit can't automatically refresh patches, and it would end up
> adding a messy patch to the end of the queue to represent the refreshing?
dgit in the default quilt mode insists on simply adding new patches.
Even if you were prepared to --quilt=smash, the existing patch queue
in debian/patches probably wouldn't apply anyway, so the result of
your proposed new .orig and merge would be produce an incomprehensible
tree. Neither dgit nor dpkg-source could work with it.
Somehow someone would have to refresh the patch stack. dgit can't do
that by itself because there might not be a single commit
corresponding to the upstream tarball; that even if there is there is
no reasonable way to find i; and anyway the patches might have
conflicts (which perhaps the user resolved during the merge).
The only way to make all this work is for the NMUer to explicitly set
out to rebase the patch queue (perhaps using some tool like gbp).
Ian.
--
Ian Jackson <[email protected]> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
