On July 24, 2019 10:43:57 AM UTC, Phil Morrell <[email protected]> wrote:
>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.
Since use of a public VCS isn't universal among free software projects, the
implication is that one could take a non-free upstream tarball, dump it into
git on salsa and magically make it free. I think this is a ridiculous concept.
>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.
I've been a Debian contributor for over a decade. I've never built a package
for upload from anything other than dpkg-buildpackage. I've used gbp (as well
as git-dpm and doing it manually) for patch management.
This entire discussion feels to me like a small group of developers trying to
tell the rest of us "my way or the highway". We are perfectly capable of
phasing out obsolete workflows without a hammer like a GR (remember dpatch).
I probably have better things to do with my time than learning from scratch how
to contribute to Debian.
Scott K
