Hello Ian,
On Sat, Oct 29, 2016 at 09:47:42PM +0100, Ian Jackson wrote:
> 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 ?I'm suggesting you take all of them -- I just didn't mention all of them in my e-mails. Sorry for not being clearer. > > 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. I would not be in favour of that practice. To my mind, the act of sponsorship is and should be limited to applying a PGP signature to the .changes and .dsc files (sponsors tend to dput the package too, but that's just for convenience). Of course, a sponsor won't be willing to apply a signature if they don't deem the package ready for upload, but in giving feedback they're acting in the role of reviewer -- which is a role open to non-DDs. I see this as important because it emphasises that the package upload is the responsibility of the sponsee, and they're no less responsible for dealing with bugs etc. than a DD/DM would be. When they run `dch -r` they are taking responsibility for that upload. Having all sponsees take that step is important for maintaining that sense of responsibility. It's also a way of respecting the work of sponsees, as being on the same level as that of DDs/DMs. Anyway, this isn't really a discussion for this bug report. What do you think about adding a commit to suggest having them delete the tag, if they added it? > > > 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. Indeed. I think we can safely ignore patches-applied gbp repositories for now. Someone might come up with a sensible test case at some point. > > 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). Thanks for explaining that. Sounds like we should leave that part of the manpage as it is. -- Sean Whitton
signature.asc
Description: PGP signature
