Control: tags -1 patch Hi again Sean. Thanks for the quick reply.
> Instead, I'd like to add text to say something about the kinds of > packages for which the workflow is unsuitable. I'd already been > thinking about submitting a patch to do that since the recent discussion > on -devel, and I think it might be sufficient to close this bug.[1] This is a good approach. Let me quote yur preferred wording from your patch. (I find it easier to deal with this inline as prose than as an attachment. And I'd like Daniel's opinion, as someone who has to deal with "not their own" packages, before concluding that we have the wording right.) > +This workflow is less suitable for some packages. When the Debian > +delta is very complex, with large parts not expected to ever be merged > +upstream, it might be preferable to maintain the delta as a rebasing > +patch series. If this applies to your package, consider > +dgit-maint-gbp(7), and see Debian bug #720177. This is good text but it's a little weaker than I would prefer. Lack of a coherent patch stack is a problem if the individual patches are hard to extract from the history, which occurs when the patches need adjustment or conflict resolution to conform to new upstreams, or cannot be easily separated. And I think the point about not merging upstream cuts both ways. Things that _are_ expected to go upstream may need to be distinguished from ones which don't. The key question is whether the patches need to be maintained as a downstream delta for any time. How about: This workflow is less suitable for some packages. When the Debian delta contains multiple pieces which interact, or which you aren't going to be able to upstream soon, it might be preferable to maintain the delta as a rebasing patch series. ? Thanks, Ian.
