Sean Whitton writes ("Bug#840153: Feedback, and dgit-maint-gbp(7)"):
> Hope the following is useful!
>
> Feedback on dgit-sponsorship(7)
> ===============================
Thanks, yes!
> 1. I think the manpage should suggest using pristine-tar(1) to move
> tarballs around, rather than uploading them to a webserver. Most of the
> people working on d-mentors are familiar with the tool, and it avoids an
> extra upload step and an extra download step in the workflow. Newbies
> can just use github for everything, which they like.
>
> See my wip.tutorials branch for a patch adding the relevant info that
> you can cherry-pick.
I'll take a look.
> 2. A lot of sponsees just prepare a standard gbp repo, without knowing
> what dgit is. Sponsors can upload these with dgit, but at present the
> manpage seems to imply that the sponsee has to be aware of dgit in order
> for this to be possible.
>
> Indeed it would be beneficial for the sponsor to upload with dgit in
> this kind of case. The sponsor can suggest that the sponsee considers
> working from the dgit HEAD for future uploads -- the sponsee, if new to
> the project, might be highly encouraged to learn that patches-unapplied
> is not mandatory.
>
> The only issue is the debian/* tag. Will dgit refuse to push until the
> sponsor deletes the tag applied by the sponsee? Or is it okay so long
> as the tag is applied to the correct commit?
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.
> 3. Rather than saying that the sponsee should specify the --quilt=
> option needed in the handoff, I think it would be clearer just to say
> that the sponsee should provide a sample `dgit push` command, containing
> all relevant options (except perhaps --overwrite). The sponsor can get
> all the information they need from this sample command.
...
> 4. I suspect that the tutorial would be easier to follow if git+origs
> based handoff were part of the sponsee workflow section as a
> subsection.
Those sound reasonable.
> I've made a commit to my wip.tutorials branch that you can cherry-pick
> if you agree.
>
> 5. Does the dgit import-dsc command exist yet? :)
It's on my WIP branch.
> 6. A lot of sponsees submit their work to the sponsorship-requests
> pseudo-package, even if they have a regular sponsor. At present the
> manpage implies that you have to send the e-mail to a DD. There's a
> commit on my branch adding some references to the RfS procedure.
Great.
> 7. It would be good if the final section didn't assume the package was
> non-NEW. Though in that case, since the review is likely to be
> involved, it would probably be best just to request the sponsee put
> their work in git.
It's possible to import a package which isn't in the archi ve with
dgit -pPACKAGE import-dsc /path/to/sponsee's.dsc +sponsee
in a fresh repo.
I also found that some of the instructions in dgit-sponsorship were
quite .... unortunate. In particular the instructdions to look at
refs/dgit-intern/quilt-cache are harmful, because I don't want to
encourage people to look there.
So I am going to make dgit quilt-fixup have an option to explictly
save the generateed dgit view.
> Feedback on dgit-nmu-simple(7)
> ==============================
>
> 1. Small patch to the third paragraph in my branch: s/maintainer's
> workflow/maintainer's git workflow/.
>
> 2. I can't see why the workflow wouldn't work for a new upstream
> version. Could you explain, either just to me or in the manpage?
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.
> 3. Instead of saying "edit debian/changelog", why not write `dch --nmu
> Apply upstream's fix for foo bug. && git commit`? Personally I find
> that easier to read than "introduce a ~ version". Similarly `dch -r`
> instead of "edit debian/changelog to prepare for release".
>
> I've made a commit to my wip.tutorials branch that you can cherry-pick
> if you agree. Fair enough if you think the current way is easier to
> read.
Maybe your way is easier. But what I wanted to do is avoid people
creating git trees that contain finalised version numbers but may not
contain everything that is going to be in that version. I think this
is poor practice. It can lead to accidental overwriting of changes,
in some combinations of circumstances.
> 4. Might be worth mentioning explicitly that you can't upload to DELAYED
> yet. Commit available in my branch.
Sure.
> Feedback on dgit-user(7)
> ========================
>
> This is a really cool manpage!
This is my #1 priority use case for dgit :-).
> 1. Should explain what "binary package name" is. Patch available in my
> branch.
>
> 2. Should probably say "patches-applied packaging branches without a .pc
> directory". Patch available in my branch.
>
> 3. The apt guys say that `dpkg -i foo.deb && apt-get install -f` is
> deprecated. It can often decide that the best way to fix the situation
> is remove foo. You're now supposed to use `apt install ./foo.deb`.
> Unfortunately, jessie's apt doesn't support it. Patch available in my
> branch adding a mention. Later we can make that the main content of the
> section.
Thanks.
> dgit-maint-dgit(7)
> ==================
>
> Available as a commit in my wip.tutorials branch that you can
> cherry-pick if you like it.
I'll have to look at this. I assume you mean dgit-maint-gbp.
> Does --gbp work fine for a patches-applied gbp repository? Since gbp
> supports this (the gbp author says so), there might be some around. If
> dgit would get confused in this case, this manpage should mention that
> it assumes patches-unapplied, and possibly refer to dgit-maint-merge(7).
Yes. It should. --gbp assumes patches-unapplied.
How does gbp tell the difference between a patches-applied and
patches-unapplied branch ?
I think a gbp patches-applied branch could probably be pushed with
--quilt=dpm, but I haven't tested it. The reason why a non-default
quilt mode is needed is that neither dpm or gbp branches contain
patches (in debian/patches/*) for changes to upstream gitignore.
> I mentioned pbuilder because a lot of gbp users use it, so I thought it
> was important to include.
Sure.
Thanks for all your help!
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.
