Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On Mon, 2019-08-26 at 23:59:09 +0200, Thomas Goirand wrote:
> On 7/26/19 4:40 PM, Andy Simpkins wrote:
> > Personally I see no reason to mandate such a change, with policy only
> > recommending / preferring the proposed changes. Furthermore I accept
> > that the policy should strongly recommend (i.e. require an explanation
> > why not) for NEW packages.
> As per our discussion in Debconf, we're attempting to remove Python 2
> from Bullseye. So, I decided to commit myself to try to do one Python 2
> removal per day. Doing so, I often encounter very badly maintained
> packages (ie: far behind upstream, bugs, no py3 support even if upstream
> has it, you name it...). And often, I get these packages maintained on a
> proprietary platform, where I have no write access. As a result, I'm
> forced to either register on the said non-free platform, and use a
> workflow which I very much dislike. It's either that ... or I just
> ignore the VCS fields, and the VCS becomes outdated, missing my upload,
> with a very good chance that it will never get updated. That's really
> bad for any future contributor that probably will also encounter the
> same problem, with on top, my changes not commited. Add on top of this
> that when you do 'apt-get source foo', then apt suggests to fetch the
> sources from that non-free platform, which has outdated sources. How do
> you explain this to a Debian newbie that wants to start contributing to
> Debian? This really doesn't make sense at all.
I read a mass of conflated arguments there that make any such
discussion quite difficult IMO.
I fully understand, and agree myself with, not wanting to use a
proprietary platform as the *primary* site for one's projects, to
avoid lock-in, to support free-software ideals, etc. I do have
accounts, and even secondary mirrors on some of these though.
As maintainers we are expected to interact with upstreams, and submit
our changes there (not just for others benefit, but also for our own,
to avoid future conflicting changes, and to make Debian needs known),
which seems it would still be unnacceptable to you. Should we then ban
any such upstream from getting into Debian? That seems like a complete
non-starter TBH, or do you expect that's fine, but someone else then
needs to do the dirty work for you? If so, what's the difference with
people in Debian maintaining the packages wherever?
Another thing I extract from your reply is that you are assuming we'd
have all repos in salsa being write-for-all, and using the debian/
namespace. That implies a very big social change, with many as yet
undefined social norms, that feels being sneaked in as an aside.
There's also the problem with out-of-date repos or unmaintained
packages. We are supposed to file NMU bugs with patches anyway. I've
also seen repos being out-of-sync with what it's in the archive on
*salsa*. The problem with unresponsive maintainers has not really
changed, we have procedures for that. I don't see why people that
cannot upload to the Debian archive should expect to be able to
automatically have write-access to random packaging repos either?
(And this all seems rather odd, given that we are talking about git,
while _D_VCS being one of its common selling points.)
There's also the problem with the workflows. I find anything that is
not packaging-only to be so attrocious to deal with that I rather
prefer to use «apt source» and go from there. I also extract from your
reply you'd like to force a single packaging workflow. Having to do
my packaging work on anything that is not packaging-only would make
that work miserable for me.
And then there's the «force to use salsa». I've got a few secondary
mirrors there too (such as for the dpkg suite), and I use the platform
(in the same way I'd use github or others) to interact with packagers
or upstreams that host there, but I'd be extremely unhappy with being
forced to use it. And I'd rather remove the Vcs fields from the packages
I maintain. See <https://wiki.debian.org/Teams/Dpkg/AliothEscape> for
some of reasons why I didn't switch the dpkg suite to salsa. For the
other package I maintain, I switched away from Alioth long long time
ago, and have been very happy since. Alioth was also supposed to be
a long-term hosting platform, but TBH I expect my self-hosting to last
longer than Salsa too.
> How do you handle such case, if not enforcing some kind of rules? Well,
> that's what motivated me to start this discussion. However, I'll let Sam
> take over, and see how it develops.
We already have procedures (NMUs, salvaging, etc) and common
infrastructure (Debian Archive, Debian source, BTS, etc) for everything
you describe above. I only see gratuituous enforcement for one's
preferred options here TBH. :(
Thanks,
Guillem
Reply to: