Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #13350 > unrolled thread

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

Back to article view | Back to linux.debian.project

Contents

  [RFC] Extending project standards to services linked through Vcs-* Dominik George <natureshadow@debian.org> - 2023-08-21 17:10 +0200
    Re: [RFC] Extending project standards to services linked through  Vcs-* Jeremy Stanley <fungi@yuggoth.org> - 2023-08-21 18:40 +0200
      Re: [RFC] Extending project standards to services linked through  Vcs-* Dominik George <natureshadow@debian.org> - 2023-08-21 22:20 +0200
      Re: [RFC] Extending project standards to services linked through Vcs-* Ángel <debian-project@debian.16bits.net> - 2023-08-30 04:20 +0200
    Re: [RFC] Extending project standards to services linked through Vcs-* Russ Allbery <rra@debian.org> - 2023-08-21 18:50 +0200
      Re: [RFC] Extending project standards to services linked through  Vcs-* Dominik George <natureshadow@debian.org> - 2023-08-21 19:30 +0200
    Re: [RFC] Extending project standards to services linked through Vcs-* Ángel <debian-project@debian.16bits.net> - 2023-08-30 05:10 +0200
      Re: [RFC] Extending project standards to services linked through Vcs-* Dominik George <natureshadow@debian.org> - 2023-08-30 11:10 +0200
        Re: [RFC] Extending project standards to services linked through Vcs-* Russ Allbery <rra@debian.org> - 2023-08-30 19:00 +0200
          Re: [RFC] Extending project standards to services linked through Vcs-* Sam Hartman <hartmans@debian.org> - 2023-08-30 20:20 +0200
          Re: [RFC] Extending project standards to services linked through Vcs-* Diederik de Haas <didi.debian@cknow.org> - 2023-08-30 21:00 +0200
            Re: [RFC] Extending project standards to services linked through Vcs-* Ian Jackson <ijackson@chiark.greenend.org.uk> - 2023-09-04 19:50 +0200
          Re: [RFC] Extending project standards to services linked through Vcs-* Ben Hutchings <ben@decadent.org.uk> - 2023-09-03 17:40 +0200
        Re: [RFC] Extending project standards to services linked through Vcs-* Ángel <angel@debian.16bits.net> - 2023-08-31 04:10 +0200
          Re: [RFC] Extending project standards to services linked through Vcs-* Diederik de Haas <didi.debian@cknow.org> - 2023-08-31 12:00 +0200

#13350 — [RFC] Extending project standards to services linked through Vcs-*

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#13372

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

[toc] | [prev] | [next] | [standalone]

#13353

Dominik George <natureshadow@debian.org> 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 (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Mon, Aug 21, 2023 at 09:48:26AM -0700, Russ Allbery wrote:
> Dominik George <natureshadow@debian.org> 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

[toc] | [prev] | [next] | [standalone]

#13373

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.

[toc] | [prev] | [next] | [standalone]

#13374

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#13375

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

[toc] | [prev] | [next] | [standalone]

#13376

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?

[toc] | [prev] | [next] | [standalone]

#13377

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#13381

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.

[toc] | [prev] | [next] | [standalone]

#13380

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#13378

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

[toc] | [prev] | [next] | [standalone]

#13379

[Multipart message — attachments visible in raw view] — view raw

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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.project

csiph-web