Hello Ian, 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.
On Sat, Oct 29, 2016 at 05:12:42PM +0100, Ian Jackson wrote:
> > 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.
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.
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"
> > 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.
Right. I've added a commit to my branch to include that.
> 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.
Okay. Let me know when these are done and I can take another look at the
manpage.
> > Feedback on dgit-nmu-simple(7) ==============================
> >
> > 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.
Yes. It's actually a regular annoyance in the RFS process. Sponsee's
always run `dch -r` because when they submit a version for review, it is
ready for upload to the best of their knowledge. But inevitably there
is feedback from more experienced individuals. And then the sponsee
tends to forget to re-run dch -r so that the timestamp is later than all
their latest changes.
> This is my #1 priority use case for dgit :-).
Interesting. As you've probably realised, my primary motivation for
contributing to dgit is reducing the amount of volunteer time spent on
busywork, so we can fix bugs instead.
> > 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 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.
> 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.
Right, I thought it might be something to do with that.
I've added a commit saying that the tutorial is for patches-unapplied.
> Thanks for all your help!
Thanks for your feedback.
--
Sean Whitton
signature.asc
Description: PGP signature
