[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa




On July 24, 2019 10:43:57 AM UTC, Phil Morrell <debian@emorrp1.name> 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


Reply to: