Hi Dominik

You proposal looked reasonable, yet at the same time something seemed
to be off.

After some pondering, I think it may be going for the wrong problem.




On 2023-08-21 at 17:00 +0200, Dominik George wrote:

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.

Is this really an issue?

These terms make perfect sense but, isn't everyone pretty much doing it already? Are there cases where *some* non-maintainers are invited to
contribute through the VCS while others are not? (*)


Rather, I think the problem statement would be that people don't know
the "right way to contribute" to the package.

Some maintainers will prefer the BTS.
Others will like to receive patches against the VCS. Or pull requests.
Against the master branch. Or main. Or devel. None of them, against the
last stable.
The maintainer may internally use GitHub issues. Or a Launchpad
project. Or use any of many other systems to track issues.


Not knowing the procedure. [for this specific package] → Trying to
contribute in some way that seemed appropriate → Turns out it isn't → Failure.

A typical case would be a maintainer which has no problem accepting contributions through GitHub. It just happens not to notice issues
opened there (yet contributors think they did what was expected), and
checks them only once a year.
For the argument's sake, let's suppose that the maintainer reviews theGitHub issues and pull requests on New Year's Eve, processing everything opened in the last year, by anyone.

It doesn't break the equality terms. Everyone contributing through
GitHub is treated the same. But it is nevertheless a Bad experience.

(It may be that "maintainers must ensure that the VCS is accessible
under the same conditions as the Debian BTS to anybody" was expected to
cover "They must look at issues opened in GitHub as often as they look
at the BTS" as well? It's nt clear what "under the same conditions" was
trying to cater)


*Disabling* the embedded VCS means for contribution is one way to
signal it's not the expected way, but only incidentally.


I don't know what would be the proper way to mark the expected way to contribute. Ideally, a good old "CONTRIBUTING" file, but that might be considered too cumbersome and barely followed. Adding a field listing
the preferred (or allowed) way to contribute would do, but that would
mean adding yet another field.




Best regards


(*) You mention

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

but these would still be possible.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-08-21 at 16:37 +0000, Jeremy Stanley wrote:

On 2023-08-21 17:00:04 +0200 (+0200), Dominik George wrote:
[...]

A concrete implementation for GitHub repositories would be to
disable issues and PRs

[...]

As an aside, unless something has changed very recently, GH does not
give you a way to disable PRs (issues yes but not PRs).

If that has suddenly become possible, I have around a thousand
projects I help maintain upstream on a non-GitHub (open source) code
forge and would love to have a way to disable PRs on all the GH
mirrors of those. For now we run a periodic bot that scans for open
pull requests and closes them with a comment telling people where to
find our contributor workflow documentation.

Hi Jeremy

https://docs.github.com/en/communities/moderating-comments-and-conversations/limiting-interactions-in-your-organization should be able to do
that.

Regards

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Ángel,

On 2023-08-21 at 17:00 +0200, Dominik George wrote:

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.

Is this really an issue?

These terms make perfect sense but, isn't everyone pretty much doing it already? Are there cases where *some* non-maintainers are invited to contribute through the VCS while others are not? (*)

Yes, my proposal is based on two very specific encounters, where
contributors were more or less pushed to use the VCS instead of the
BTS.

I was myself in another case where I wanted to contribute to a package
and found out that it is maintained on GitHub, but I did not get to
find out whether I could have contributed without using GitHub. However,
pull requests were accepted on GitHub, which fulfills my description
of "being invited", and GitHub having exclusive terms also of "other
being not invited".

So yes, it is a real issue, albeit a corner case.

Rather, I think the problem statement would be that people don't know
the "right way to contribute" to the package.

Some maintainers will prefer the BTS.
Others will like to receive patches against the VCS. Or pull requests. Against the master branch. Or main. Or devel. None of them, against the
last stable.
The maintainer may internally use GitHub issues. Or a Launchpad
project. Or use any of many other systems to track issues.

Not knowing the procedure. [for this specific package] → Trying to contribute in some way that seemed appropriate → Turns out it isn't → Failure.

That's not the problem at hand. The problem at hand is where the
maintainer thinks the "proper" way is using the VCS, and chooses
a VCS that is less inclusive than Debian systems.

It does not help to tell the contributor that the VCS is the proper
way to contribute, because they cannot use it. And that's exactly
what I would like to prevent.

A typical case would be a maintainer which has no problem accepting contributions through GitHub. It just happens not to notice issues
opened there (yet contributors think they did what was expected), and
checks them only once a year.
For the argument's sake, let's suppose that the maintainer reviews theGitHub issues and pull requests on New Year's Eve, processing everything opened in the last year, by anyone.

It doesn't break the equality terms. Everyone contributing through
GitHub is treated the same. But it is nevertheless a Bad experience.

(It may be that "maintainers must ensure that the VCS is accessible
under the same conditions as the Debian BTS to anybody" was expected to
cover "They must look at issues opened in GitHub as often as they look
at the BTS" as well? It's nt clear what "under the same conditions" was trying to cater)

I don't think that's part of the argument. My request does not make
any assumptions on how often and when and why a maintainer handles contributions. It only asks for offering the same access conditions
to the used platforms to everyone.

*Disabling* the embedded VCS means for contribution is one way to
signal it's not the expected way, but only incidentally.

I don't know what would be the proper way to mark the expected way to contribute. Ideally, a good old "CONTRIBUTING" file, but that might be considered too cumbersome and barely followed. Adding a field listing
the preferred (or allowed) way to contribute would do, but that would
mean adding yet another field.

Well, the consequence of my proposal, if we take it further, would be:

If a maintainer lists their VCS in the source package, then they need
to accept people using it. And if they accept people using it, they
must ensure that everyone can do so under the same conditions.

Maintainers of course MUST always accept bugs and patches (accept as
in receive and consider, not merge into their package) through the
BTS. We have this provision in place, and I have no intentions to change
that.

-nik

-----BEGIN PGP SIGNATURE-----

iKcEABYKAE8WIQSk6zxRYJYchegBkTEK5VTlRg4b3QUCZO8GDjEaaHR0cHM6Ly93 d3cuZG9taW5pay1nZW9yZ2UuZGUvZ3BnLXBvbGljeS50eHQuYXNjAAoJEArlVOVG DhvdYGMA/2Ji70KsAeG/pbwZA12EVSz5PBOizqI3QSatDS7rgeNLAQD9P5c3neqf oPvj0w6VBNz+6YSmeDEh3DkMamx+dhn4Bg==
=jVu3
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dominik George <natureshadow@debian.org> writes:

Well, the consequence of my proposal, if we take it further, would be:

If a maintainer lists their VCS in the source package, then they need to accept people using it. And if they accept people using it, they must
ensure that everyone can do so under the same conditions.

Maintainers of course MUST always accept bugs and patches (accept as in receive and consider, not merge into their package) through the BTS. We
have this provision in place, and I have no intentions to change that.

So I want to say up front that personally I think the Debian packaging for every package in Debian should ideally have an existence on Salsa and all maintainers should set up their personal Salsa configurations so that they receive merge request notifications and other communication from it, even
if they primarily do development elsewhere.

This is what I did when this discussion started a while back, even in
cases where my packages have dual (or more) existences elsewhere, and I've never had trouble with it. One of the significant advantages of Git as a technology (which is now by far the most common way to maintain Debian packages) is that it's fairly trivial to allow the repository to live in multiple places.

But my concern with this approach to trying to push people in that
direction is that it's starting to sound to me a bit like the FSF's failed effort to attempt to get free software projects to refuse to ever mention
or point to non-free software. Debian rejected this communication
strategy, to the great ire of the FSF, and quite rightfully so.

Free software is a broad community with a wide range of opinions about
both what ideal role free and non-free software should play in our
computing lives and about what practical steps should be taken to achieve
those ends. Some Debian developers are free software activists; some are
not, and simply want to work together on a shared distribution maintained
using free software principles. There is widespread disagreement within
that community about the appropriate role of GitHub. I'm saying this not
to restart that conversation, which I don't think will be that productive,
but only to acknowledge that diversity in our community.

The way Debian has dealt with this historically is to say that the
*Debian* part of your work needs to follow our free software principles,
and we stay out of the rest of your business. I respect that your
proposal is trying to stick to that line and is only talking about the
Debian packaging. But I'm worried that it's getting close to the line
that the FSF crossed, in which they tried to tell people that they weren't permitted to talk about certain tools because they were ideologically incorrect.

I agree with all of your points about the importance of allowing
contributions from the full range of Debian contributors and not forcing
people to create GitHub accounts (which they may not even be able to do)
in order to contribute to Debian packaging. I would strongly encourage everyone using Git to maintain Debian packages to mirror that repository
on Salsa and accept contributions there so that Debian can continue to
move towards standardizing a contribution flow. But if the primary
development is happening on GitHub and that's the first place that any
changes are pushed to and that's the current state of the packaging, I'm dubious the merits of telling people not to point to GitHub outweigh the frustrations.

I think there are two very important points here that, were either of them different, would probably change my mind:

* GitHub allows anonymous Git cloning and anonymous browsing of the
repository without creating an account.
* The Vcs-Git and Vcs-Browser fields have never promised that you can
submit pull requests, file issues, or do any form of interactive
development at those sites. They *only* point to a possibly read-only
Git repository. For many years, in all of my packages, they pointed to
a gitweb instance I run myself that literally no one else has access to.

In other words, GitHub fulfills the narrow promise of Vcs-Git and
Vcs-Browser: here is the current read-only packaging repository, available
to everyone.

I completely agree with you that it's not appropriate for a Debian package maintainer to refuse to consider submissions that don't go through GitHub.
But we already address that by relying on patches to the BTS as the common denominator, and provide Salsa for people who don't like patches and
prefer merge requests. If someone is telling all bug submitters to their package that they will only look at submissions via GitHub, this makes me
sad and I think the project has some grounds to ask them to stop doing
that. But I don't think that's the same as your proposal.

If we as a project are ready to move forward towards a world in which the project is standardizing on a contribution flow, or even on a VCS, I would
be delighted. That would naturally lead towards requiring all projects be
in Salsa or some successor, and I'm all in favor. But until such time as
we're willing to make that decision, I'm dubious about singling out GitHub
as verboten when we allow Vcs-* fields to point to read-only Git
repositories with a subset of the functionality that GitHub provides to
people without an account. In other words, if we're going to require
Vcs-* point to an actual forge and not just a VCS repository, great, but
we're not there yet.

I recognize your point about how GitHub excludes certain users and I in no
way mean to defend this. This is a real feature of Salsa, even more than
I was previously aware. But I also don't think this is a strong enough argument on which to rest this proposal. The BTS interaction is also
exclusive in the sense that not everyone's email is going to get through;
some of it is going to be filtered or rejected for all sorts of reasons. Communication is lossy.

I completely agree that we should have fallbacks that are as universal as possible, and that we should not be telling people they are required to
use GitHub. But this doesn't feel like the right hammer to me.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I tend to generally agree with Russ.
But I wonder if there are things we could do on a technical front
Are there things we could do to remove barriers and get to a point where
we can make salsa a valid contribution channel?

Things like

* Add a way to mirror issues from salsa to github for people who want to
develop on github

* Or mirror salsa issues/MRs to bts for people who want that?

I.E. can we solve this problem by trying to leverage the idea that you
can have multiple git repos and mapping that to things like merge
requests and issues too
so that people can be first class on salsa even if development also
happens elsewhere?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, 30 August 2023 18:46:38 CEST Russ Allbery wrote:

So I want to say up front that personally I think the Debian packaging for every package in Debian should ideally have an existence on Salsa and all maintainers should set up their personal Salsa configurations so that they receive merge request notifications and other communication from it, even
if they primarily do development elsewhere.

I would really like that all packaging is *available* on Salsa, even if it is just in readonly 'mode'. Some don't have any Vcs repo listed and that makes contributing much harder then needed.

I'm fine if maintainers don't want to deal with Salsa MRs, even though I find it
convenient. But knowing *how* contributions can be made would be welcome.
So something like a "Patch-submission" field (in debian/control) seems useful. -----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZO+PXQAKCRDXblvOeH7b blu4AP43J1zQlRqZub4W2pQ10KeJqL9QVZDFsNcS3jol1KBN5QD+MgMl6p8bumnH 3FjizaQAG9ZBYjChhqaR8GTg2E1pBgM=
=qAKa
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Dominik

On 2023-08-30 at 11:04 +0200, Dominik George wrote:

On 2023-08-21 at 17:00 +0200, Dominik George wrote:

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.

Is this really an issue?

These terms make perfect sense but, isn't everyone pretty much doing it already? Are there cases where *some* non-maintainers are invited to contribute through the VCS while others are not? (*)

Yes, my proposal is based on two very specific encounters, where
contributors were more or less pushed to use the VCS instead of the
BTS.

Pushing *everyone* to use the VCS instead of the BTS does not
"discriminate on who is invited to contribute through the VCS".

Particularly if such VCS has no intrinsic bias about who may use it. It
does violate the "and you must also allow contributing through BTS"
rule, but that must be a separate one.

I was myself in another case where I wanted to contribute to a
package and found out that it is maintained on GitHub, but I did not
get to find out whether I could have contributed without using
GitHub.

In my view, this is precisely a case of "the people don't know the accepted/preferred way to contribute"

However, pull requests were accepted on GitHub, which fulfills my
description of "being invited",

If other random people had pull requests that were being discussed or
even merged, then I would consider it a sign that they were accepted.

If it's just a project with zero pull requests and you mean there's a
GitHub button, then I don't think it can be considered an invitation by
the maintainer.
See the Jeremy case. GitHub UI shows such an option but PR are not
actually accepted on GitHub.

and GitHub having exclusive terms also of "other being not invited".

This may be an important difference. I am only considering choices made
by the maintainer. Not by the VCS hosting or their upstream ISP.

If GitHub were blocking access from Russia [1] *and the maintainer
chose GitHub so that Russian couldn't contribute*, I would consider
that discriminating. If the maintainer is not aware of that, they are
not being discriminated _by the maintainer_ (indirectly, they would
still unable to access it, anyway)-
Interestingly, it might even happen that *nobody* wanted to
discriminate the target of a block, such as a firewall rule overly
inclusive, or a block based on an outdated atabase.



[1] They are not: https://github.blog/2022-03-02-our-response-to-the-war-in-ukraine/

That's not the problem at hand. The problem at hand is where the
maintainer thinks the "proper" way is using the VCS, and chooses
a VCS that is less inclusive than Debian systems.

It does not help to tell the contributor that the VCS is the proper
way to contribute, because they cannot use it. And that's exactly
what I would like to prevent.

Ok. I misread your statement as covering actions/choices by the
maintainer, not by the platform.
I think this would be more clear if stating the properties that such
VCS would need to have (e.g. not requiring a minimum age), both Debian-
based and external, rather than just saying "the same conditions as the
Debian BTS"

Maintainers of course MUST always accept bugs and patches (accept as
in receive and consider, not merge into their package) through the
BTS. We have this provision in place, and I have no intentions to
change that.

I completely agree with that.


Regards

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu Aug 31, 2023 at 3:23 AM CEST, �ngel wrote:

If GitHub were blocking access from Russia [1] *and the maintainer

[1] They are not: https://github.blog/2022-03-02-our-response-to-the-war-in-ukraine/

The (other) case I was thinking of was Iran. I'm glad people from Iran
were 'unbanned' [2] as "a breakthrough: we have secured a license from
the US government to offer GitHub to developers in Iran."

Because "GitHub respects and abides by US law", it seems to me that any contributions to Debian packages hosted on GitHub is dependent on
whether the US gov is OK with it. I think that's very problematic.

Just as age should not be an obstacle [3], neither should country of origin
or residence.

Cheers,
Diederik

[2] https://github.blog/2021-01-05-advancing-developer-freedom-github-is-fully-available-in-iran/
[3] https://lore.kernel.org/all/20141124074206.09cddd26@lwn.net/


-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZPBg9QAKCRDXblvOeH7b bjTSAQD5s1unAVw0bYDj4YHXCyVm0IOCAQmc3v/fHMNaiDiBnQEAy1HnNs3GhSir kFKOEFeovzns3fldOB4efMcyRCOqkgg=
=Ruki
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 2023-08-30 at 09:46 -0700, Russ Allbery wrote:
[...]

* GitHub allows anonymous Git cloning and anonymous browsing of the
repository without creating an account.

[...]

Up to a point. It's rather easy to hit a rate limit when browsing
anonymously.

Ben.


--
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.


-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmT0pUAACgkQ57/I7JWG EQmDbA//cewsbjkuTS172YWougdDeXLdG6fjKyTXBOmaArk8ww5I7GWCp+Z4CrKC dN6Mk/eRbRcWENcdTGPQmc6toSUYtTT/HzOBfbXUln1VXwh09YB3Mzh/jKKq1mDD YhKI+mchHA+irusMnonWliRW2/qR53gXW/Eo2YaLHNgVBaHwX4cOYdxjOvTHDBs1 4bZs+Ip7hIRkEySm/DP2FzHO4YSL3Jo3ZXGVMPnNUyvPhtQ3QgxaDvLQ5t8bL4pS 7t8LBLEv4qVlgVNNIBQi00yTSlbUy2TpHB5LWpgK2ZWdTitvjdxSYAJ84cvrLKpA zfdUiIZxd3A/5yo/XK9xPCFaHKOdth5XBOYOi+p53Dd11cL1EtkXLMPRs9iMLP23 OqhwdzLRckFWPRS9T8msUPeR6Qfz5u5LfPmBhtOwedw+eZdjgI1Ea2NjCUpzA5Z+ lp8RxGvHcKbjzNdRldJ9pcy8NzgPkfyJxG9dEAXgANIDbPCjTZ4XdUy6+c8X3KRN 0HMY5R1Uk2LQnJF8hKP87EXfjrEt7x4N/gN0DiM/fCyF0YEwnfc0+e49arhNFEtr hjrfoPGEc3IN+udsbo5Q+UnkeDvrEcV3zFXnAf1FSZf8PWW8Li+oIL4pX0IvGKyj gBl3JmsTTQMgsEdBFHYYNnyR4afndmbwbuM3/9oUJkWBA4Etd5I=
=u3m7
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05

Hi. Thanks for giving me an excuse for some axe-grinding :-).

David Bremner writes ("Re: [RFC] Extending project standards to services linked through Vcs-*"):

I have a project currently hosted off salsa. I'm willing to have
read-only mirror, but I'm not willing to put much effort in to it.

Knowing you, I think you probably do your uploads with dgit. I hope
you find it convenient, but of course there is another advantage:
Your git history is available via "dgit clone".

Unlike the Vcs-Git tree, mirrors on non-free services, etc., the
package contents seen by a user of "dgit clone" is precisely equal to
what is actually in the archive, and therefore actually useable by
someone who isn't a Debian expert.

I wrote more about this in detail in 2021
https://diziet.dreamwidth.org/9556.html

Maybe someone(TM) should take on the task of mirroring, in some way that makes it clear this is not a place to send MRs. In a small way, that
could be a technical (partial) solution to a social problem. It could
even be automated based on Vcs-Git urls.

Automatically importing from the archive doesn't get you git history,
of course. But that's what dgit does. Currently it does that
client-side: if the maintainer didn't use dgit to upload, it must
import the .dsc, and therefore the user doesn't get the git history.

I'm hoping we can increase the availability of reliable and useable
git histories, by increasing dgit adoption, and, eventually, deploying tag2upload.

Ian.

--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)