Re: [RFC] Extending project standards to services linked through Vcs-*

[Ian Jackson]

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 JacksonThese 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.

Re: [RFC] Extending project standards to services linked through Vcs-*

[Ben Hutchings]

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.



signature.asc
Description: This is a digitally signed message part

Re: [RFC] Extending project standards to services linked through Vcs-*

[David Bremner]

Diederik de Haas  writes:

> 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.

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.
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.

Re: [RFC] Extending project standards to services linked through Vcs-*

[Diederik de Haas]

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.09cdd...@lwn.net/



signature.asc
Description: This is a digitally signed message part.

Re: [RFC] Extending project standards to services linked through Vcs-*

[Ángel]

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

Re: [RFC] Extending project standards to services linked through Vcs-*

[Diederik de Haas]

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.

signature.asc
Description: This is a digitally signed message part.

Re: [RFC] Extending project standards to services linked through Vcs-*

[Sam Hartman]

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?

Re: [RFC] Extending project standards to services linked through Vcs-*

[Russ Allbery]

Dominik George  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 a

Re: [RFC] Extending project standards to services linked through Vcs-*

[Dominik George]

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


signature.asc
Description: PGP signature

Re: [RFC] Extending project standards to services linked through Vcs-*

[Ángel]

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.

Re: [RFC] Extending project standards to services linked through Vcs-*

[Ángel]

On 2023-08-21 at 16:37 +, 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

Re: [RFC] Extending project standards to services linked through Vcs-*

[Dominik George]

Hi,

> 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.

Thanks for the hint!

You are indeed right – disabling pull requests is not possible on GH.

In any case, making it prominently clear that pull requests are not
the primary way of contribution, would be sufficient for the case in
point.

-nik


signature.asc
Description: PGP signature

Re: [RFC] Extending project standards to services linked through Vcs-*

[Dominik George]

Hi,

On Mon, Aug 21, 2023 at 09:48:26AM -0700, Russ Allbery wrote:
> Dominik George  writes:
> 
> > 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.
> 
> This implies that Salsa is happy to create accounts for people under the
> age of 13, since the implicit statement here is that Debian's own Git
> hosting infrastructure is less excluding than GitHub.
> 
> That's a somewhat surprising statement to me, given the complicated legal
> issues involved in taking personal data from someone that young, so I want
> to double-check: is that in fact the case?

That is, in fact, the case.

And no, it's not not legally complicated to collect personal data from
children. If we, for now, only look at COPPA and GDPR, the laws relevant
for the US and EU, respectively, the situation is:

 * You can accept consent from children, if:

   * it can be, objectively, assumed that they can overlook the
 consequences of the data collection
 → we can assume that, if someone sucessfully contributes to
   a Debian package, they are knowledgable enough, given that
   Salsa only collects a pseudonym and an e-mail address

   * you don't use the data for marketing or profiling purposes
 → we don't do that

   * you don't direct commercial advertisements at children
 → we don't do that

   * you don't explicitly advertise your service to children
 (as in, promising them a benifit exceptionally attractive for
 children)
 → we don't do that

Even if we did one of the above things, we'd still be able to accept
children if they have parental consent, which is a bit tricky (but,
should we get to this at some point, be outsourced to a trusted partner,
like Teckids, who has expertise in that field). If we get to this point,
I will certainly fight to accept children with parental consent, even
if it implies some work. GitHub and a lot of other services, however,
in addition to not being able to allow children without parental
consent, also don't accept them *with* parental consent.


As it stands, Salsa (and a lot of other Debian services) are not
GDPR-compliant because they do not have a privacy statement making the
above clear, but while related, let's not mix that into this thread.


Cheers,
Nik



signature.asc
Description: PGP signature

Re: [RFC] Extending project standards to services linked through Vcs-*

[Jeremy Stanley]

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.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: [RFC] Extending project standards to services linked through Vcs-*

[Russ Allbery]

Dominik George  writes:

> 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.

This implies that Salsa is happy to create accounts for people under the
age of 13, since the implicit statement here is that Debian's own Git
hosting infrastructure is less excluding than GitHub.

That's a somewhat surprising statement to me, given the complicated legal
issues involved in taking personal data from someone that young, so I want
to double-check: is that in fact the case?

(US embargoes are indeed going to be a problem for any service hosted in
the United States, and possibly an issue, depending on the details, for
any maintainer with US citizenship even if they're using a site hosted
elsewhere.  I would not dare to venture an analysis without legal advice.)

-- 
Russ Allbery (r...@debian.org)