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

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

Debian and Non-Free Services

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

Contents

  Debian and Non-Free Services Sam Hartman <hartmans@debian.org> - 2019-09-12 19:40 +0200
    Re: Debian and Non-Free Services Ansgar <ansgar@43-1.org> - 2019-09-12 20:00 +0200
      Re: Debian and Non-Free Services Norbert Preining <preining@logic.at> - 2019-09-13 01:30 +0200
      Re: Debian and Non-Free Services Bernd Zeimetz <bernd@bzed.de> - 2019-09-16 19:10 +0200
        Re: Debian and Non-Free Services Vincent Bernat <bernat@debian.org> - 2019-10-04 17:10 +0200
    Re: Debian and Non-Free Services Marc Haber <mh+debian-project@zugschlus.de> - 2019-09-12 22:30 +0200
      Re: Debian and Non-Free Services "Dr. Bas Wijnen" <wijnen@debian.org> - 2019-09-13 00:50 +0200
        Re: Debian and Non-Free Services Ansgar <ansgar@43-1.org> - 2019-09-13 08:20 +0200
        Re: Debian and Non-Free Services Wouter Verhelst <wouter@debian.org> - 2019-09-13 20:40 +0200
    Re: Debian and Non-Free Services Pierre-Elliott Bécue <peb@debian.org> - 2019-09-12 22:50 +0200
      Re: Debian and Non-Free Services Yao Wei <mwei@debian.org> - 2019-09-13 01:00 +0200
        Re: Debian and Non-Free Services Pierre-Elliott Bécue <peb@debian.org> - 2019-09-13 20:20 +0200
          Re: Debian and Non-Free Services "Yao Wei (魏銘廷)" <mwei@debian.org> - 2019-09-15 23:00 +0200
            Re: Debian and Non-Free Services Pierre-Elliott Bécue <peb@debian.org> - 2019-09-16 15:40 +0200
    Re: Debian and Non-Free Services Scott Kitterman <debian@kitterman.com> - 2019-09-13 02:40 +0200
      Re: Debian and Non-Free Services Guillem Jover <guillem@debian.org> - 2019-09-13 04:30 +0200
      Re: Debian and Non-Free Services Louis-Philippe Véronneau <pollo@debian.org> - 2019-09-13 18:00 +0200
      Re: Debian and Non-Free Services Norbert Preining <norbert@preining.info> - 2019-10-04 18:00 +0200
        Re: Debian and Non-Free Services Norbert Preining <norbert@preining.info> - 2019-10-04 18:30 +0200
        Re: Debian and Non-Free Services Charles Plessy <plessy@debian.org> - 2019-10-05 01:20 +0200
          Re: Debian and Non-Free Services Bernd Zeimetz <bernd@bzed.de> - 2019-10-09 16:20 +0200
            Re: Debian and Non-Free Services Charles Plessy <plessy@debian.org> - 2019-10-10 00:20 +0200
      Re: Debian and Non-Free Services Ole Streicher <olebole@debian.org> - 2019-10-04 20:40 +0200
        Re: Debian and Non-Free Services Florian Weimer <fw@deneb.enyo.de> - 2019-10-04 21:20 +0200
        Re: Debian and Non-Free Services Andreas Tille <andreas@an3as.eu> - 2019-10-06 08:50 +0200
        Re: Debian and Non-Free Services Ole Streicher <olebole@debian.org> - 2019-10-06 15:00 +0200
        Re: Debian and Non-Free Services Jose-Luis Rivas <ghostbar@debian.org> - 2019-10-07 05:30 +0200
        Re: Debian and Non-Free Services Michael Lustfield <michael@lustfield.net> - 2019-10-08 10:10 +0200
          Re: Debian and Non-Free Services "Xavier" <yadd@debian.org> - 2019-10-08 13:10 +0200
          Re: Debian and Non-Free Services Bastian Blank <waldi@debian.org> - 2019-10-08 17:00 +0200
            Re: Debian and Non-Free Services Bastian Blank <waldi@debian.org> - 2019-10-09 00:40 +0200
          Re: Debian and Non-Free Services Ondrej Novy <novy@ondrej.org> - 2019-10-09 12:40 +0200
        Re: Debian and Non-Free Services Bernd Zeimetz <bernd@bzed.de> - 2019-10-09 16:20 +0200
          Re: I think We're Done: Debian and Non-Free Services Sam Hartman <hartmans@debian.org> - 2019-10-09 17:40 +0200
    Re: Debian and Non-Free Services Joerg Jaspert <joerg@debian.org> - 2019-09-13 09:40 +0200
    Re: Debian and Non-Free Services Andy Simpkins <rattusrattus@debian.org> - 2019-09-13 13:00 +0200
    Re: Debian and Non-Free Services Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> - 2019-09-13 13:10 +0200
      Re: Debian and Non-Free Services MJ Ray <mjr@phonecoop.coop> - 2019-09-13 15:00 +0200
        Re: Debian and Non-Free Services Sam Hartman <hartmans@debian.org> - 2019-09-13 17:00 +0200
          Re: Debian and Non-Free Services Scott Kitterman <debian@kitterman.com> - 2019-09-13 17:40 +0200
            Re: Debian and Non-Free Services Norbert Preining <norbert@preining.info> - 2019-09-13 18:00 +0200
            Re: Debian and Non-Free Services Bernd Zeimetz <bernd@bzed.de> - 2019-09-16 19:00 +0200
    Re: Debian and Non-Free Services Holger Levsen <holger@layer-acht.org> - 2019-09-13 13:40 +0200
    Re: Debian and Non-Free Services Ian Jackson <ijackson@chiark.greenend.org.uk> - 2019-09-13 19:50 +0200
    Re: Debian and Non-Free Services Bart Martens <bartm@debian.org> - 2019-09-15 20:10 +0200
    Re: Debian and Non-Free Services Anonymous <anonymous@hoi-polloi.org> - 2019-09-16 23:10 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#11088

Hi,

On 10/5/19 1:10 AM, Charles Plessy wrote:
> I make this comment as the person who some years ago took the initiative
> to take over the "Debian" Github group, that was more or less abandonned
> and apparently not controlled by somebody related to Debian.  It was a
> definitely a bitter experience that I do not feel to reproduce...

does that still exist? Might make sense to share some work there. Not
sure, though, with so many github haters out there, I might want to keep
my stuff under my own account which makes it easier to stop <insert
whatever you like here> people from doing not so sane things.


Brend


-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

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

#11091

> On 10/5/19 1:10 AM, Charles Plessy wrote:
> >
> > I make this comment as the person who some years ago took the initiative
> > to take over the "Debian" Github group, that was more or less abandonned
> > and apparently not controlled by somebody related to Debian.  It was a
> > definitely a bitter experience that I do not feel to reproduce...

Le Wed, Oct 09, 2019 at 04:10:12PM +0200, Bernd Zeimetz a écrit :
> 
> does that still exist? Might make sense to share some work there. Not
> sure, though, with so many github haters out there, I might want to keep
> my stuff under my own account which makes it easier to stop <insert
> whatever you like here> people from doing not so sane things.

Hi Bernd,

no pressure at the moment.  It was painful to make something new happen,
but now it is low-maintenance routine, that I share with Yaroslav.
Still I would not mind be replaced.  The workflow is to get GPG-signed
emails, check the web of trust, and add people to the group.

Have a nice day,

-- 
Charles Plessy
Akano, Uruma, Okinawa, Japan

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

#11061

Hi Thomas,

Thomas Goirand <zigo@debian.org> writes:
> On 9/13/19 2:35 AM, Scott Kitterman wrote:
>> It's based on a false premise.  No one is forced to use any VCS to
>> maintain Debian packages.  If you don't want to talk to GitHub, send
>> a patch to the BTS.
>
> If one slenderizes about a particular VCS URL, it means it is where he
> wishes to have pull/merge requests from. Otherwise, what's the point?

No, it just means "This is the canonical location for the packaging
repository." Nothing more. There is no information about the workflow
preferred by the maintainer.

You may guess that people using github accept pull requests, but you
even can't see whether they actually like them -- there are many reasons
why people use github, and PRs may not necessarily the specific reason
for the repository.

On the other hand, you *know* that BTS patches are accepted, so I do not
see why they would not be the preferred way when in doubt.

And, BTW, sometimes contributing to a Debian package requires
communication with upstream (creating a bug report or discussing a
patch); in this case you cannot avoid the use of non-free services
anyway, since you are then bound to their choice of services.

Best regards

Ole

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

#11062

* Ole Streicher:

> You may guess that people using github accept pull requests, but you
> even can't see whether they actually like them -- there are many reasons
> why people use github, and PRs may not necessarily the specific reason
> for the repository.

And you can't disable this Github feature, so its availability tells
others nothing about maintainer preferences.

I've grudgingly submitted pull requests over Github, only to be told
that no, we don't accept patches here. 8-(

But nevertheless, I think the canonical source location is useful
information, especially in a machine-readable form.

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

#11068

On Sat, Oct 05, 2019 at 11:42:50PM +0200, Thomas Goirand wrote:
> 
> So, if someone is not using Github's "advanced" features, like pull
> requests and so on, why that person would care about using Github more
> than using Salsa?

While I personally think that using something else than Salsa is not
helpful for team maintenance the answer to this question from Norberts
point should be clear.
 
> > You may guess that people using github accept pull requests, but you
> > even can't see whether they actually like them -- there are many reasons
> > why people use github, and PRs may not necessarily the specific reason
> > for the repository.
> 
> I'm just trying to understand here...
> Apart from the "close to upstream" bit, what would be the reasons?

I also don't understand this.
 
Kind regards

     Andreas. 

-- 
http://fam-tille.de

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

#11069

Thomas Goirand <zigo@debian.org> writes:
>> No, it just means "This is the canonical location for the packaging
>> repository." Nothing more. There is no information about the workflow
>> preferred by the maintainer.
>
> So, if someone is not using Github's "advanced" features, like pull
> requests and so on, why that person would care about using Github more
> than using Salsa?

Maybe they has already a Github account and does not want to create
another one as long as this is not really necessary. Maybe they is more
familar with the Github user interface than with the Gitlab one. Maybe
they thinks that the repository is better visible if on Github. Maybe
they does the job for an institution which requires to have the
repositories in the institutional organization. Maybe the primary
packaging is done for another distribution (or a special repository).

Sure: most of these are not really strong reasons, and I would always
try to convince people to move to Salsa. And for Debian Astro (as for
many other teams), the requirement is to have the repository on Salsa,
and I am fully behind that.

But that still does not mean that I see reasons why people use Github
for Debian packages and (to come back to the original discussion) having
a repository on Github does *not* automatically mean a preference in the
workflow. So, if someone has the repository there, you can still expect
that BTS patches are welcome. You stated the opposite, that that was all.

>> And, BTW, sometimes contributing to a Debian package requires
>> communication with upstream (creating a bug report or discussing a
>> patch); in this case you cannot avoid the use of non-free services
>> anyway, since you are then bound to their choice of services.
>
> This is bound to the choice of each package maintainer, and has nothing
> to do with the rules for packaging within Debian. In other words: what
> you are discussing is IMO off-topic.

Your (?) argument was: contributing to a Debian package shall not
require to use non-free services. My counter-argument is: contributing
to a Debian package often requires communication with upstream (provide
patches, look for fixes from upstream etc.), where non-free service may
be involved. So, the goal of not requiring non-free services cannot be
reached anyway.

Nevertheless, I see many good reasons why we should enforce people to
use Salse. Homogenizing the packaging a bit makes team maintenance a lot
easier, allows better QA, non-discriminating access (didn't Github
exclude Iran developers a while ago?) etc. But "not enforce people to
use a non-free service when contributing to Debian" is IMO not
convincing.

Cheers

Ole

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

#11072

On 10/5/19 17:42, Thomas Goirand wrote:
> So, if someone is not using Github's "advanced" features, like pull
> requests and so on, why that person would care about using Github more
> than using Salsa?

Because the person already has an account in GitHub, and has code there.
And when asked to show their code they point to their GitHub account
that's where they centralize all of their code.

There's people that's not interested in having accounts created based on
their beliefs about stuff but because of pragmatism, and if your
employer is already using GitHub and your favorite open source projects
are already using GitHub (which is the case for most people), then just
use GitHub and leave the others behind because: why would you need
another account for the same stuff? Can't they pull from your GitHub
repository after all?

-- 

   \\\\__.    https://wiki.debian.org/JoseLuisRivas
___\\\\'/___  rsa4096/D278F9C15E5461AA3C1E2FCD13EC43EEB9AC8C43

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

#11080

On Sat, 5 Oct 2019 23:42:50 +0200
Thomas Goirand <zigo@debian.org> wrote:

> So, if someone is not using Github's "advanced" features, like pull
> requests and so on, why that person would care about using Github more
> than using Salsa?
> 
> > You may guess that people using github accept pull requests, but you
> > even can't see whether they actually like them -- there are many reasons
> > why people use github, and PRs may not necessarily the specific reason
> > for the repository.  
> 
> I'm just trying to understand here...
> Apart from the "close to upstream" bit, what would be the reasons?

I prefer GitHub over Debian's GitLab instance because:

- It's significantly more stable
  + I've seen "GitLab is not responding" more times than I can keep track of
  + I've also seen a large number of 500 and 504 errors (at least 1x/wk)
  + This reliably fails: https://salsa.debian.org/api/v4/groups/debian
- GitHub often addresses problems quickly; this is rare with salsa
- GitHub takes efforts to provide root cause analysis & lessons learned
- Decisions are discussed, instead of drunken thoughts over chips and salsa
- I've witnessed more changes accepted by GitHub
  + Salsa concerns have been met with, "fix it in upstream or go away"
  + GitHub concerns have been met with, "this is now an internal incident"
    & often fixed within a month or two
- It's a well-known standard solution where many people already have accounts
- GitHub admins are *much* more responsive (for obvious reasons)

I prefer GitHub over GitLab, in general, because:

- GitHub doesn't require javascript just to browse repos
- GitHub is often *much* faster to respond to feature requests
- GitHub stages upgrades; improving general stability
- GitLab has a *lot* of weird ACL bugs
  + I can create projects in groups that I have no access to maintain
  + I can create branches that won't let me force push (git push -f)
  + I can create projects that let me push to anything except master
  + I can be given maintainer access to a team owning those projects, but still
    run into all the same problems

I can provide a much longer list, but it shouldn't be necessary. There are
plenty of reasons why someone would prefer GitHub over other alternatives.
Attempting to force one option only going to further divide our community.

-- 
Michael Lustfield

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

#11081

Le Mardi, Octobre 08, 2019 09:49 CEST, Michael Lustfield <michael@lustfield.net> a écrit: 
> On Sat, 5 Oct 2019 23:42:50 +0200
> Thomas Goirand <zigo@debian.org> wrote:
> 
> > So, if someone is not using Github's "advanced" features, like pull
> > requests and so on, why that person would care about using Github more
> > than using Salsa?
> > 
> > > You may guess that people using github accept pull requests, but you
> > > even can't see whether they actually like them -- there are many reasons
> > > why people use github, and PRs may not necessarily the specific reason
> > > for the repository.  
> > 
> > I'm just trying to understand here...
> > Apart from the "close to upstream" bit, what would be the reasons?
> 
> I prefer GitHub over Debian's GitLab instance because:
> 
> - It's significantly more stable
>   + I've seen "GitLab is not responding" more times than I can keep track of
>   + I've also seen a large number of 500 and 504 errors (at least 1x/wk)
>   + This reliably fails: https://salsa.debian.org/api/v4/groups/debian
> - GitHub often addresses problems quickly; this is rare with salsa
> - GitHub takes efforts to provide root cause analysis & lessons learned
> - Decisions are discussed, instead of drunken thoughts over chips and salsa
> - I've witnessed more changes accepted by GitHub
>   + Salsa concerns have been met with, "fix it in upstream or go away"
>   + GitHub concerns have been met with, "this is now an internal incident"
>     & often fixed within a month or two
> - It's a well-known standard solution where many people already have accounts
> - GitHub admins are *much* more responsive (for obvious reasons)
> 
> I prefer GitHub over GitLab, in general, because:
> 
> - GitHub doesn't require javascript just to browse repos
> - GitHub is often *much* faster to respond to feature requests
> - GitHub stages upgrades; improving general stability
> - GitLab has a *lot* of weird ACL bugs
>   + I can create projects in groups that I have no access to maintain
>   + I can create branches that won't let me force push (git push -f)
>   + I can create projects that let me push to anything except master
>   + I can be given maintainer access to a team owning those projects, but still
>     run into all the same problems
> 
> I can provide a much longer list, but it shouldn't be necessary. There are
> plenty of reasons why someone would prefer GitHub over other alternatives.
> Attempting to force one option only going to further divide our community.

I heard the same thing when we were migrating from Office to LibreOffice (x ~100.000 users). Freedom has a price.
Thank you very much to the salsa teams for the great work they do

Cheers,
Xavier

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

#11084

Hi Michael

On Tue, Oct 08, 2019 at 02:49:32AM -0500, Michael Lustfield wrote:
> - It's significantly more stable
>   + I've seen "GitLab is not responding" more times than I can keep track of
>   + I've also seen a large number of 500 and 504 errors (at least 1x/wk)

We have around 0,1% failure rate.

>   + This reliably fails: https://salsa.debian.org/api/v4/groups/debian

- Known, bug in the API, can be worked aroung with
  "?with_projects=false".
- WTH do you even try this?
- I doubt that GitHub got similar large groups.

> - GitHub often addresses problems quickly; this is rare with salsa

https://salsa.debian.org/salsa/support/issues?scope=all&utf8=%E2%9C%93&state=all&author_username=mtecknology
is empty.  So which problems are you talking about.

> - GitHub takes efforts to provide root cause analysis & lessons learned

https://bits.debian.org/2019/08/salsa-postmortem-docker-registry.html

> - Decisions are discussed, instead of drunken thoughts over chips and salsa

-v?

Okay, no need to go further.

Bastian

-- 
Knowledge, sir, should be free to all!
		-- Harry Mudd, "I, Mudd", stardate 4513.3

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

#11085

Hi Michael

On Tue, Oct 08, 2019 at 04:41:41PM +0200, Bastian Blank wrote:
> > - GitHub takes efforts to provide root cause analysis & lessons learned

We are all volunteers, which is not the case for GitHub employees.  So
thank you for volunteering to help the Salsa admins with communication
in the future.

Regards,
Bastian

-- 
I'm a soldier, not a diplomat.  I can only tell the truth.
		-- Kirk, "Errand of Mercy", stardate 3198.9

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

#11086

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

Hi,

út 8. 10. 2019 v 10:06 odesílatel Michael Lustfield <michael@lustfield.net>
napsal:

>   + I can create branches that won't let me force push (git push -f)
>   + I can create projects that let me push to anything except master
>

https://docs.gitlab.com/ee/user/project/protected_branches.html

-- 
Best regards
 Ondřej Nový

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

#11087

On 10/5/19 11:42 PM, Thomas Goirand wrote:
>> No, it just means "This is the canonical location for the packaging
>> repository." Nothing more. There is no information about the workflow
>> preferred by the maintainer.
> 
> So, if someone is not using Github's "advanced" features, like pull
> requests and so on, why that person would care about using Github more
> than using Salsa?

because they are free to do so.
If pornhub would offer a git server with more features than github and
gitlab, people would probably start to use it, too. Free people in a
free world are free to use whatever they like to, even if you think that
the service they like to use is not free or is not your taste or
whatever else.

If you don't like it, clone it, push it, mirror it. You are free to do so.

But please stop telling other people what they are supposed to do or not.

Git is like your favorite car. You can buy one from VW with
maybe-broken-software, it will serve you well until it dies.
Or you can build your own "free" car, it will serve you well until it dies.

Would you like it that various people tell you not to drive your lovely
VW because it is not free?


-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

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

#11089 — Re: I think We're Done: Debian and Non-Free Services

>>>>> "Thomas" == Thomas Goirand <zigo@debian.org> writes:

    Thomas> Not discussing the issue itself, just (respectfully)
    Thomas> commenting on your reply.

    Thomas> If there's no valid reason to prefer Github, then it would
    Thomas> be very easy to just enforce the use only Salsa. Therefore,
    Thomas> I'm just trying to understand what the incentives are. Your
    Thomas> reply saying "because they can" sounds a bit silly to me,
    Thomas> and isn't very helpful...

I understand this desire, and it sounds like you've gotten some valuable
feedback.

One of the things I'm supposed to do under Constitution 4.1 (9) is lead
and facilitate discussions.
We've received significant feedback on debian-devel that long mailing
list threads have a cost to a number of members in our community.

One of the things I noticed while compiling the recent Git summary is
that the discussion of Github and non-free services took up much more
space in the discussion than anything else.
Even though we knew very early on that we weren't going to be able to
change anything.


We've reached the point where we need to be done with this thread both
here and on debian-devel.

If you want to continue learning about Github usage in Debian I
recommend reaching out respectfully to individuals who have participated
in the discussion and asking them if they would be willing to help you
continue to learn.

I'm sure we'll revisit this all some day.  Technologies, usage patterns,
etc change.  Perhaps some cross-project service on a free platform will
gain momentum.

But for now, we're done.

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

#10931

On 15523 March 1977, Sam Hartman wrote: 

>   Subject: Free Software Needs Free Tools 

I think the subject does not fit the content. Its more like "Forbid DDs
to use certain services".

>   No Debian contributor should be expected or encouraged, when working to 
>   improve Debian, to use non-free tools.  This includes proprietary web 
>   services.  We will ensure this, insofar as it is within Debian's 
>   collective control.

>   For example, Vcs-Git fields in source packages must not refer to 
>   proprietary git code management systems.  Non-Debian services are 
>   acceptable here so long as they are principally Free Software.

>   We encourage all our upstreams to use Free/Libre tools.

>   We recognise that metadata in Debian which describes the behaviour of 
>   those outside our community, for example fields which refer to upstream 
>   source management systems, may (in order to be accurate) still need to 
>   refer to proprietary systems.

I think that, should this pass, it has negative effects for Debian, not 
positive ones.

While we should clearly NOT encourage the use of things like github, the
only thing we IMO should forbid is where it actually hurts us as a
project. Say, it really doesnt matter if i git clone
github.com/something to get what the maintainer is working on right now
- the one "official" source for the Debian package is whats in the
archive - but if the maintainer wants to use GitHub issues as their
mainplace for bug tracking and not the BTS, thats bad. So if anything,
we should forbid such things (as we discourage anyways already).

Difference IMO is where the main, authorative, place for something is.
source in git is just some source in git, the authorative one for Debian
is the upload. You can easily put an NMU on top (or take over package)
While for bugs its the BTS, not some whatever system somewhere.

-- 
bye, Joerg

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

#10932

On 12/09/2019 18:30, Sam Hartman wrote:
> Subject: Free Software Needs Free Tools
> 
>    No Debian contributor should be expected or encouraged, when working
>    to improve Debian, to use non-free tools.  I don't believe that anyone within Debian will have a problem with this 
statement.


>    This includes proprietary web services.  
Clearly no issue here either - web services are an instance of a 
software application/tool so the above statement holds.


>    We will ensure this, insofar as it is within Debian's
>    collective control."Ensure" is perhaps the wrong word here.  I submit that "Encourage" may 
be a better choice.
Just because you, and I, believe that "No Debian contributor should be 
expected or encouraged... ...to use any non-free tools" does not mean 
that we should *prevent* them from doing so.  The decision to do so 
should vest solely with the contributor.  *providing* that their doing 
so does not force other contributors to use non-free tools.
It would however, IMO, be acceptable to enforce this for Debian's own 
tools, and infrastructure.  Just not for packages where Debian is not 
the 'root upstream'.


> 
>    For example, Vcs-Git fields in source packages must not refer to
>    proprietary git code management systems.  Non-Debian services are
>    acceptable here so long as they are principally Free Software.
Your example strikes of forcing people to use an entirely free system 
for their development process.  If we are to encourage and support 
freedom that means that we must also accept that other people have the 
freedom to use proprietary git code management systems.
Again if this example is bound within the relm of Debian services, tools 
and root packages then IMO this would be acceptable.


>    We encourage all our upstreams to use Free/Libre tools.
Again I can't see anyone within Debian having a problem with this 
statement.


> 
>    We recognise that metadata in Debian which describes the behaviour
>    of those outside our community, for example fields which refer to
>    upstream source management systems, may (in order to be accurate)
>    still need to refer to proprietary systems.
That is what I am trying to say, and this statement would appear to be 
at odds with your example above.

I guess what I am trying to say is for upstream packages distributed 
within Debian (the vast majority) we should ensure that contributors to 
these packages are able to contribute using exclusively free tools and 
software.  This does not prohibit the upstream from using proprietary 
services, only that their must be a method to contribute without being 
forced to use those services.

Where the Debian project *is* the upstream then of cause we should eat 
our own dog food and use entirely FLOSS tools.

/Andy

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

#10933

чт, 12 сент. 2019 г. в 20:30, Sam Hartman <hartmans@debian.org>:
>   Subject: Free Software Needs Free Tools
>
>   No Debian contributor should be expected or encouraged, when working
>   to improve Debian, to use non-free tools.  This includes proprietary
>   web services.  We will ensure this, insofar as it is within Debian's
>   collective control.
>
>   For example, Vcs-Git fields in source packages must not refer to
>   proprietary git code management systems.  Non-Debian services are
>   acceptable here so long as they are principally Free Software.

I'd say strict NO to this proposal. While our goal is to enhance free software
and to encourage its usage, we should not limit our developers' freedom
to use any tool they would like.

>   We encourage all our upstreams to use Free/Libre tools.
>
>   We recognise that metadata in Debian which describes the behaviour
>   of those outside our community, for example fields which refer to
>   upstream source management systems, may (in order to be accurate)
>   still need to refer to proprietary systems.
>


-- 
With best wishes
Dmitry

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

#10936

Fri Sep 13 12:06:35 GMT+01:00 2019 Dmitry Eremin-Solenikov :
 
> чт, 12 сент. 2019 г. в 20:30, Sam Hartman :
 
> > For example, Vcs-Git fields in source packages must not refer to
> > proprietary git code management systems. Non-Debian services are
> > acceptable here so long as they are principally Free Software.
> 
> I'd say strict NO to this proposal. While our goal is to enhance free software
> and to encourage its usage, we should not limit our developers' freedom
> to use any tool they would like.
 
Both answers limit developers' freedom of choice. NO allows maintainers to
host package sources on github or whatever, but that arguably
requires future maintainers, co-maintainers and so on to use it too.
 
I have some sympathy with the "send a patch to bugs.debian.org" view.
Do any developers ignore those and tell people to join github to use its
private version of pull requests? I know I have patches ignored in there
but I don't remember being told to go sign a github contract.

-- 

MJR - please excuse brevity because this was sent while mobile

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

#10937

>>>>> "MJ" == MJ Ray <mjr@phonecoop.coop> writes:

 
    MJ> I have some sympathy with the "send a patch to bugs.debian.org"
    MJ> view.  Do any developers ignore those and tell people to join
    MJ> github to use its private version of pull requests? I know I
    MJ> have patches ignored in there but I don't remember being told to
    MJ> go sign a github contract.

I believe we have a strong consensus in the Git Packaging Round 1 thread
on debian-devel that maintainers are expected to process patches
submitted through the BTS.  Telling someone they needed to use Github
would be unacceptable in my mind.

--Sam

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

#10938

On Friday, September 13, 2019 10:52:37 AM EDT Sam Hartman wrote:
> >>>>> "MJ" == MJ Ray <mjr@phonecoop.coop> writes:
>     MJ> I have some sympathy with the "send a patch to bugs.debian.org"
>     MJ> view.  Do any developers ignore those and tell people to join
>     MJ> github to use its private version of pull requests? I know I
>     MJ> have patches ignored in there but I don't remember being told to
>     MJ> go sign a github contract.
> 
> I believe we have a strong consensus in the Git Packaging Round 1 thread
> on debian-devel that maintainers are expected to process patches
> submitted through the BTS.  Telling someone they needed to use Github
> would be unacceptable in my mind.

Is anyone actually doing that?  I think this entire thread is nothing more 
than a stalking horse for Ian's crusade to get everyone to use dgit and we 
should just move on.

Scott K

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web