Ian Jackson [04/Mar 6:31pm GMT] wrote: >> We haven't discussed making dgit start honouring its *own* quilt modes >> embedded in upload tags. If we were to do that, then with regard to >> *this* bug, there would no longer be a regression for our flagship >> dgit-maint-merge(7) workflow, in that you wouldn't have to do any local >> git configuration and wouldn't ever have to pass quilt mode options. > > I don't think there is any meaningful distinction here: dgit makes > DEP-14 tags which contain the quilt mode information, which look > for these purposes exactly like tag2upload tags. > > But, there is a complication. dgit needs to support NMUs, uploads to > distro A taking history from distro B, etc. A dgit-based NMU > (dgit-nmu-simple(7)) uses git history which may have maintainer tag > containing dgit metadata. It might also have dgit-generated dsc > imports. More generally, work done from the dgit view (from > dgit-repos, or from an archive/ tag) needs to *not* use the > maintainer's quilt mode. It must default to --linear. > > A maintainer who uses --quilt=single might git merge from the dgit > view. If an NMUer used --quilt=linear, they would then have the > NMUer's DEP-14 and archive/ tags in their history pointing to the > previous upload, but we wouldn't want to switch their quilt mode. > > I forget the details of the precise algorithm in git-debpush, but if I > remember rightly it is partly driven by in-tree information (eg the > changelog) and maybe some knowledge of Debian version number > conventions. I think that's fine for git-debpush. > > For dgit I think we need to think about this in a much more serious > way. Ie, we should understand what the data model is, and try to > develop an algorithm which we can prove will DTRT. (Or at least, > won't do anything too bad.) > > I don't think we should try to guess whether something is using an NMU > git workflow by looking at Maintainer information, or version number > conventions. That information is political, and doesn't necessarily > tell you what git workflow is in use. We need to determine the git > workflow by looking at the git history. > > I'm not even sure that my scenario of a --quilt=single maintainer > merging a --quilt=linear NMU is distinguishable, in the data, from a > co-maintainer decision to change quilt mode. > >> We would still have lost 'dpkg-source --commit' with single-debian-patch >> but I think we are both okay with that. > > Yes. > >> Taking a step back, it would overall be simpler if dgit and git-debpush >> worked the same way with regard to quilt modes embedded in tags: they >> both defer to the latest one written by either of them unless overridden >> on the command line. > > If we can come up with a sound way for dgit to determine the quilt > mode automatically, then I think we should adopt the same algorithm in > git-debpush. > > (Or to put it another way: any algorithm that is correct enough for > dgit's much wider range of use cases, is also corredct for > git-debpush. But not vice versa.)
All good points, I agree with the importance of the issues you raise here. >> So how about we extend #1111423 to making dgit read quilt modes out of >> both its own tags and git-debpush's tags, and consider that to resolve >> the regression I'm concerned about in this bug? > > I think this is a fine plan for resolving #1031793, but having read > what I write above you may think it will be too difficult. Not sure quite what you mean -- too difficult such that we should look for an alternative solution to #1031793? -- Sean Whitton
signature.asc
Description: PGP signature
