Heisann,
[ for reference, the general discussion was held in 2019 already, in a slightly ]
[ too big context [3]. ]
as many of you will know, I am heavily involved in tearing down obstacles
in the way of contributing to free and open source software (with a focus on
very young people). As a Debian Developer, I am proud to use and contribute to
a distribution that is among the top projects in that regard, by…
* …depending almost purely on its own infrastructure
* …not caring the least about any personal attributes of contributors
* …having policies in place that are (legally) acceptable by virtually
everyone, only limited by legislation, if at all
* …putting great freedom in the choice of tools into the hands of
contributors
* …actively fostering education and young people
However, there is one aspect I sometimes find to cause a break in this
outstanding pattern: The ever so often discussed maintenance of source
packages in (Git) repositories (for the sake of simplicity, I am ignoring
non-Git VCSs here).
Basically, as a quick summarization, the rules for VCS usage are:
* Maintainers are free to use a VCS for packaging, or not
* Maintainers are free to choose any VCS they like
* VCSes can optionally be linked to source packages through the VCS-*
fields [1]
* Policy somewhat requires VCSes that are linked in VC-* fields in
source packages to be pblicly accessible
* Maintainers must use the official contribution channels (i.e. the BTS)
even if they use a VCS [2]
In essence, we could, somewhat polemically, conclude that:
Packages may be developed in a VCS repository for the maintainers'
delight, but these repositories are not an official part of the
package lifecycle from a distribution perspective
Generally, not having a clear policy on that VCS package maintenance means
is, in my opinion, one of the major obstacles when trying to contribute
to Debian. Part of this is the freedom maintainers have in using these
tools. This results in variosu different approaches, two of the rather
problematic ones including using a VCS, and then frowning upon contributions
outside the VCS, and using a VCS, but then not allowing contributors to use
the VCS as well.
In contrast to the huge discussion in 2019, I would like to propose a softer
set of policies to tackle this problem, with the ultimate goal of allowing
collaboration for everyone indeendent of whether a VCS is used or not.
Besides the social challenges that come with maintainer decisions, the
measurable aspect is whether contributors can collaborate on the VCS or
not, if they want to and if the maintainer generally accepts contributions
there.
For the current picture, here is a summary of where VCS repositories linked
to source packages are currently hosted:
Debian infrastructure 181969
GitHub.com 3898
GitLab.com 334
A full ranking of the VCS hosts can be acquired using UDD with a query like
select substring(vcs_url from '(?<=://)[^/]+(?=/)') as domain,
count(vcs_url) as count from sources
group by domain order by count desc;
The issues with GitHub as an example were discussed from a freedom perspective
in 2019 in a sub-thread [4] – the essence being "GitHub is non-free, noone should
hae to use non-free services to contribute to Debian".
Instead, I'd rather like to examine the situation from an equlity perspective,
and from a perspective of extending the general tenor of DFSG (in particular,
point 5) [5] to other terms besides licenses. For instance, that would be:
"The terms of use must not discriminate against any person or group of persons."
The essential doctrine would be that we, as the Debian community, must not impose
any limitations on who can contribute, in addition to those potentially imposed
by governing laws, and that we must ensure that all people that can participate
at all can do so under the same preconditions.
For the GitHub case, the problematic terms would be that in order to register for
a GitHub account, users must be at least 13 or 16 years old (depending on the
jurisdiction) ant must not live in a country under US embargoes.
Now, some will argue that it's still optional to use the VCS, and that anybody
who wants to contribute to a package can unconditionally do so using the BTS,
even if the maintainers use a VCS repository. That would, of course, require
a stric policy placing all maintainers under the obligation to accept contributions
through the BTS, even if they use a VCS.
But, I want to go one step further and think about who is invited to do what.
If *some* people are invited to contribute through the VCS, and others are not,
this does not fulfill the requirement of equality. So, if we invite one person
to contribute through a VCS platform, we should invite everyone to do so.
Now for the concrete implementation of this idea: I propose to add a certain
interpretation to the Vcs-* field on source packages, namely:
By denoting a VCS in the Vcs-* fields, the maintainer makes the VCS
part of the Debian packaging. Therefore, they assert that the VCS
follows the same standards as the tools and platforms of the Debian
project.
The implications of this interpretation are as follows:
* Maintainers are free to use any VCS they like for their personal
enjoyment, as long as they don't list it in the Vcs-* fields
* Maintainers are free to not accept contributions through the VCS
even if listed in Vcs-*, as long as they consistently don't accept
contributions from anyone (this includes, or even encourages, to make
VCSs read-only to non-maintainers, if equal access cannot be assured)
+ A concrete implementation for GitHub repositories would be to
disable issues and PRs on the GitHub repository; this would
suffice to implement the proposal at hand
* If generally accepting contributions through the VCS, maintainers
must ensure that the VCS is accessible under the same conditions as
the Debian BTS to anybody
Given the argumentation and proposed implementation of a "fix" at hand,
I'd like to hear some feedback on the proposal, with due consideration
for the impact of a diverse choice of platforms for minorities that you
consider unlikely as contributors ;).
Ha det,
Nik
[1] https://www.debian.org/doc/debian-policy/ch-controlfields.html#version-control-system-vcs-fields
[2] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#handling-bugs
[3] https://lists.debian.org/debian-devel/2019/09/msg00085.html
[4] https://lists.debian.org/debian-devel/2019/09/msg00149.html
[5] https://www.debian.org/social_contract#guidelines
Attachment:
signature.asc
Description: PGP signature