Hello, On Wed 19 Jun 2019 at 11:51pm +0200, Wouter Verhelst wrote:
> On Mon, Jun 17, 2019 at 11:47:38AM +0100, Sean Whitton wrote: >> We could try to write a tool which tries to guess and convert (e.g.) the >> dgit view with your changes into a maintainer workflow, but there are >> large obstacles to this working reliably. For example, there exist edge >> cases such that there is no algorithm which can determine, for any >> possible Debian source package tree committed to git, whether it is >> patches-applied or patches-unapplied. And there are so many small >> variations on workflows that such a tool would have to be very complex. > > What if you took away the necessary guesswork? > > Have dgit support a field in debian/control that, if it exists, explains > to dgit (and any other tool that might care) what the workflow type is. > This would require a categorization of all the possible git layouts, and > would initially obviously not support all of them. > > But once it exists, it would allow behaviour for a hypothetical "dgit > create-merge-request" command or some such, where if the field exists in > debian/control a merge request is posted to salsa in the correct > fashion; and if the field does *not* exist in debian/control, it would > then instead simply be a wrapper around 'git format-patch' and/or 'git > send-email'. > > This would, as an aside, also allow maintainers to express that they > would prefer merge requests in salsa over patches in the bts, so would > have use beyond dgit. This is a cool idea. I'd just like to note that I don't think we would want it to be in any way dgit-specific or labelled with 'dgit', and `dgit create-merge-request` would probably be better something in devscripts than a dgit subcommand. dgit it meant to be only for interoperation between git and the archive. If this metadata has uses beyond that, it should not be labelled 'dgit'. -- Sean Whitton
signature.asc
Description: PGP signature
