On Wed, Jul 24, 2019 at 07:34:02PM +1000, Alexander Zangerl wrote: > i detest unwarranted, imposed, uniformity. i *love* consistency. we have > had consistency in the distribution for ages. we don't need uniform > workflows. It's not (always) about mandating workflows, see Ian's careful distinction in the GitPackagingSurvey between sharing format and workflow. Your previous mail said: > as long as the resulting package aupload conforms to the specs i see no I believe this GR is about moving the needle on what those specs say - that a source tarball is no longer enough to represent the "preferred form of modification" for debian developers (to reference another thread). **If** it's decided that a debian package must have a git representation hosted on salsa as a service to users, then yes that may restrict your workflow freedom. I hope it wouldn't go as far as requiring that you literally use git-buildpackage itself, but it might say that in non-exceptional cases, tag2upload must replace dput. That's a long way off, but yes you would end up having to adapt your workflow slightly to meet the new spec. > or do you also plan to insist that your roofing contractor only uses > <insert brand> tools and only cuts the rafters with your preferred saw? To extend the analogy, no, but I would be happy insisting that they place tiles, not thatch, and that rafters are cut in accordance with local building regulation. This will incidentally turn away all thatching contractors and anyone's workflow which relies on e.g. cutting corners when out of sight. Ultimately, assume a maintainer, or a whole team of uploaders gets hit by a bus, how can we specify the definition of a "package" such that other DDs can quickly and easily take up future maintenance. -- Phil Morrell (emorrp1)
Attachment:
signature.asc
Description: PGP signature