control: tag -1 +patch Hope the following is useful!
Feedback on dgit-sponsorship(7) =============================== 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. 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? 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. I've made a commit to my wip.tutorials branch that you can cherry-pick if you agree. 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. 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? :) 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. 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. 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? 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. 4. Might be worth mentioning explicitly that you can't upload to DELAYED yet. Commit available in my branch. Feedback on dgit-user(7) ======================== This is a really cool manpage! 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. dgit-maint-dgit(7) ================== Available as a commit in my wip.tutorials branch that you can cherry-pick if you like it. 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). I mentioned pbuilder because a lot of gbp users use it, so I thought it was important to include. -- Sean Whitton
signature.asc
Description: PGP signature
