Re: Debian and Non-Free Services
> 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 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
Re: I think We're Done: Debian and Non-Free Services
> "Thomas" == Thomas Goirand 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.
Re: Debian and Non-Free Services
On 10/9/19 4:16 PM, Bernd Zeimetz wrote: > > > 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? Not discussing the issue itself, just (respectfully) commenting on your reply. If there's no valid reason to prefer Github, then it would be very easy to just enforce the use only Salsa. Therefore, I'm just trying to understand what the incentives are. Your reply saying "because they can" sounds a bit silly to me, and isn't very helpful... Cheers, Thomas Goirand (zigo)
Re: Debian and Non-Free Services
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 ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: Debian and Non-Free Services
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 people from doing not so sane things. Brend -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: Debian and Non-Free Services
Hi, út 8. 10. 2019 v 10:06 odesílatel Michael Lustfield 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ý
Re: Debian and Non-Free Services
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
Re: Debian and Non-Free Services
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
Re: Debian and Non-Free Services
On 10/8/19 9:49 AM, Michael Lustfield wrote: > On Sat, 5 Oct 2019 23:42:50 +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? >> >>> 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. You (and FWIW everyone else) didn't provide any *feature* that's missing in Salsa. I do hear the above, but I was expecting to read about features missing in Gitlab. It's nice that it doesn't seem to be the case. BTW, I do not agree that Salsa is often down, badly maintained, or buggy in general. Compared to Alioth, that's a big plus. I am also very thankful for the work done so far. Cheers, Thomas Goirand (zigo)
Re: Debian and Non-Free Services
Le Mardi, Octobre 08, 2019 09:49 CEST, Michael Lustfield a écrit: > On Sat, 5 Oct 2019 23:42:50 +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? > > > > > 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
Re: Debian and Non-Free Services
On Sat, 5 Oct 2019 23:42:50 +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? > > > 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
Re: Debian and Non-Free Services
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
Re: Debian and Non-Free Services
Thomas Goirand 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
Re: Debian and Non-Free Services
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
Re: Debian and Non-Free Services
Hi Ole, Thanks for your reply. On 10/4/19 8:18 PM, Ole Streicher wrote: > Thomas Goirand 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? s/slenderizes/advertises/ Sorry for the typo, I'm not sure how my spell-checker did that ... :) > 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? > 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? > 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. Cheers, Thomas Goirand (zigo)
Re: Debian and Non-Free Services
Le Fri, Oct 04, 2019 at 06:40:15PM +0200, Jonas Meurer a écrit : > > And a side note: please accept that others in the project have opinions > that object to yours. Not agreeing with your point of view doesn't mean > that you're silenced or censored, despite you behaving like this. Quite > on the contrary, that's what vibrant democratic debates are about ;) Hi Jonas, it is important that both sides of the argument accept to respect each other. Sadly, it is a strong pattern on the Debian mailing lists that unkind impolite thankless naysaying comes first, since it is simple to express and quicker to type... 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... In other contexts, this could be called environmental harassment. No matter if the pressure comes from different people at each time, what is sure is that working on certain areas is going to be emotionally expensive. Have a nice week-end, -- Charles Plessy Akano, Uruma, Okinawa, Japan
Re: Debian and Non-Free Services
* 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.
Re: Debian and Non-Free Services
Hi Thomas, Thomas Goirand 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
Re: Debian and Non-Free Services
Norbert Preining: >>> 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? > > Wrong. I don't care for PR, and accept them as well as patches to BTS, > whatever comes. This is FUD you are spreading. > > Anyway, consequence of the whole discussion is that I will remove all > VCS fields from my packages. I have enough of that. Huh, why should you do this? We as a project are nowhere near a consensus to deprecate Github links in VCS fields. Why would you remove your VCS fields in anticipatory obedience? And a side note: please accept that others in the project have opinions that object to yours. Not agreeing with your point of view doesn't mean that you're silenced or censored, despite you behaving like this. Quite on the contrary, that's what vibrant democratic debates are about ;) Cheers jonas signature.asc Description: OpenPGP digital signature
Re: Debian and Non-Free Services
On Sat, 05 Oct 2019, Norbert Preining wrote: > > 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? > > Wrong. I don't care for PR, and accept them as well as patches to BTS, > whatever comes. This is FUD you are spreading. Forgot to mention - one can use git and "that what should not be named" with things like git format-patch / git am in case you didn't know. So I still think having a VCS at "that what should not be named" is better than no VCS field whatsoever ... but then, it is the dark side. Enjoy Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: Debian and Non-Free Services
> > 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? Wrong. I don't care for PR, and accept them as well as patches to BTS, whatever comes. This is FUD you are spreading. Anyway, consequence of the whole discussion is that I will remove all VCS fields from my packages. I have enough of that. Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: Debian and Non-Free Services
On 9/13/19 12:51 PM, Andy Simpkins wrote: > 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. Though advertising for a non-free service through the VCS fields is indeed encouraging using such a non-free service. >> 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. Nop. For *sharing* development. That's where there's a huge difference. If you advertise for a VCS URL, it is to work with others. Otherwise, why publishing your Git repository on a public place? > 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. Nobody intend to forbid this, unless you advertise for it in the VCS URLs, which indeed, is trying to enroll others. Cheers, Thomas Goirand (zigo)
Re: Debian and Non-Free Services
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? Thomas
Re: Debian and Non-Free Services
On 9/13/19 8:14 AM, Ansgar wrote: > So assume I want to avoid using non-free DNS and CDN services, but still > contribute to Debian. How should that work as long as Debian uses these > services? If you have in mind the CDN used for security updates, well it'd be a nice idea if DSAs were thinking about moving away from that, since that's non-free. That's not what this GR is about, but maybe we should open the discussion as well. > How should one contact people using non-free mail services? > (mailto:non-free is probably not better than https://non-free...) That's not what this GR is about either. > Of course Debian can stop using CDN services and provide a worse > experience for users, but why? Because we care about the 4 freedom that we have with free software. Why not, instead, create and use our own CDN service? https://www.fromdev.com/2011/06/create-cdn-content-delivery-network.html > Debian's goal is not to build and operate a free CDN service... Right, it's not our final goal. Right, it's easier to just use a non-free service. Though is the later what we really *should* be doing? That's a very different question. Please, let's not mix them. Yes, running our own services is time and resource demanding. But there's a reason why we've been doing that for years... If the DSA team doesn't want to do that, they have alternatives: - Don't run such a service at all (and don't use a commercial service either). - Ask for help. - Run on a commercial service, but make sure that what's underneath is fully free software, and that it'd be feasible to set it up ourselves. Cheers, Thomas Goirand (zigo)
Re: Debian and Non-Free Services
❦ 4 octobre 2019 16:57 +02, Thomas Goirand : >>> That would just lead to packages using these to no longer including the >>> Vcs-* fields... There are some valid reasons to host packages on >>> services such as GitLab or GitHub such as when they are hosted there as >>> part of the upstream project and/or for better cooperation with >>> upstream. > > It's very much fine if you still host it on Salsa, and ask upstream to > pull from your repository. > > Besides this, I found such cases pretty rare, and mostly, we get > upstream doing wrong/bad packaging, having a non-consistent with the > Debian archive debian/changelog (because they don't care our release > cycle and such), etc. Even with a very cooperative upstream, I don't see > how you would get a single and unique debian/changelog, when most also > care about Ubuntu. Do you have such concret example where Debian can use > the upstream repository without a single change? Not sure if this is what you have in mind, but: - https://github.com/Exa-Networks/exabgp/tree/debian/sid - https://github.com/edenhill/kafkacat/tree/debian -- Use the "telephone test" for readability. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: Debian and Non-Free Services
On 9/16/19 6:53 PM, Bernd Zeimetz wrote: > On 9/12/19 7:49 PM, Ansgar wrote: > >> That would just lead to packages using these to no longer including the >> Vcs-* fields... There are some valid reasons to host packages on >> services such as GitLab or GitHub such as when they are hosted there as >> part of the upstream project and/or for better cooperation with >> upstream. It's very much fine if you still host it on Salsa, and ask upstream to pull from your repository. Besides this, I found such cases pretty rare, and mostly, we get upstream doing wrong/bad packaging, having a non-consistent with the Debian archive debian/changelog (because they don't care our release cycle and such), etc. Even with a very cooperative upstream, I don't see how you would get a single and unique debian/changelog, when most also care about Ubuntu. Do you have such concret example where Debian can use the upstream repository without a single change? > Either that or packages are just being removed from Debian and provided > in an external repository. That's entirely a package maintainer's decision, and so it is another package maintainer's decision to take over the work. IMO, this is FUD. Cheers, Thomas Goirand (zigo)
Re: Debian and Non-Free Services
A General Resolution might be necessary concerning potential misinterpretation of Debian Social Contract in the project. 1. "We will never make the system require the use of a non-free component." Are webservices for example gitlab.com, cloudflare.com or dns.google a required component in Debian and how do they qualify as non-/free? Thanks all!
Re: Debian and Non-Free Services
On 9/12/19 7:49 PM, Ansgar wrote: > That would just lead to packages using these to no longer including the > Vcs-* fields... There are some valid reasons to host packages on > services such as GitLab or GitHub such as when they are hosted there as > part of the upstream project and/or for better cooperation with > upstream. Either that or packages are just being removed from Debian and provided in an external repository. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: Debian and Non-Free Services
On 9/13/19 5:29 PM, Scott Kitterman wrote: > On Friday, September 13, 2019 10:52:37 AM EDT Sam Hartman wrote: >>> "MJ" == MJ Ray 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. Absolutely. Nobody should be forced to use a tool - or not. Also if you want to send a pull request and don't want to use github, clone the repo to whatever service you like and send a PR from there via the BTS. Where is the problem? -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: Debian and Non-Free Services
Le lundi 16 septembre 2019 à 04:56:19+0800, Yao Wei (魏銘廷) a écrit : > > > On Sep 14, 2019, at 02:15, Pierre-Elliott Bécue wrote: > > > >> Does this also imply we are reverting the GR on non-free sections? > >> > >> https://www.debian.org/vote/2004/vote_002 > >> > >> Yao Wei > > > > I have a clear doubt about your understanding of my email. > > > > Can you develop your point ? > > > > That was my random thought: > > If we cannot use non-free software for Debian packaging, we cannot > naturally install what we pack to examine the package. Therefore I > thought the existence of non-free section is probably doomed. > > But since non-free section is not part of Debian per DSC §5, therefore > that's not so related here. The other reason I see for it not to be really accurate is that I'm saying I'd rather keep the current situation (non-free tools like Github used to package Debian stuff) than enforce the free tooling view. If I defend the right for people to use github if they wish there is a little chance I'd advocate for removing the non-free repo. :) > Sorry for confusion, and I will try communicating carefully. > > The usage of non-free tools for packaging should be okay because we > "can" make free software out of non-free tools, though some would > think we should use free tools only to build a free society. I > believe more in harmony that the world of free software and non-free > software should be able to co-exist. This should be a philosophy > question on the position of Debian, about whether Debian is completely > non-free exclusive in every way (and whether the existence of non-free > section should be challenged again). I personally don't think we should challenge the existence of the non-free repo. > However, on the choice of VCS, I think we can REQUIRE Salsa to be on > the Vcs-Git and make Vcs-Git to be mandatory except for valid reasons. > Developers should be free to mirror their repository from the service > they would like to, but they should be two-way synchronized between > Salsa and the service. If it is possible, I'd like to propose putting > multiple Vcs-Git URLs to indicate mirrors. That could also answer the > issue that some people prefer free services instead of non-free > service used by maintainer, and can come in handy in case if Salsa is > down. I tend to see people leaving if you restrict the tools they're allowed to use, not them becoming more prone to free software in any way. Sure there'll be people eager to make the effort, but I'm afraid some will just give up contributing. I hope I made myself more understandable on this one, -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them.
Re: Debian and Non-Free Services
> On Sep 14, 2019, at 02:15, Pierre-Elliott Bécue wrote: > >> Does this also imply we are reverting the GR on non-free sections? >> >> https://www.debian.org/vote/2004/vote_002 >> >> Yao Wei > > I have a clear doubt about your understanding of my email. > > Can you develop your point ? > That was my random thought: If we cannot use non-free software for Debian packaging, we cannot naturally install what we pack to examine the package. Therefore I thought the existence of non-free section is probably doomed. But since non-free section is not part of Debian per DSC §5, therefore that's not so related here. Sorry for confusion, and I will try communicating carefully. The usage of non-free tools for packaging should be okay because we "can" make free software out of non-free tools, though some would think we should use free tools only to build a free society. I believe more in harmony that the world of free software and non-free software should be able to co-exist. This should be a philosophy question on the position of Debian, about whether Debian is completely non-free exclusive in every way (and whether the existence of non-free section should be challenged again). However, on the choice of VCS, I think we can REQUIRE Salsa to be on the Vcs-Git and make Vcs-Git to be mandatory except for valid reasons. Developers should be free to mirror their repository from the service they would like to, but they should be two-way synchronized between Salsa and the service. If it is possible, I'd like to propose putting multiple Vcs-Git URLs to indicate mirrors. That could also answer the issue that some people prefer free services instead of non-free service used by maintainer, and can come in handy in case if Salsa is down. Yao Wei, still trying to clear my thoughts and find a place to stand. (Sent from a phone, sorry for HTML email.)
Re: Debian and Non-Free Services
On Thu, Sep 12, 2019 at 01:30:24PM -0400, Sam Hartman wrote: > > I'm trying to move a thread from -devel. > > Ian Jackson responded [1] to part of a consensus discussion on Git > recommendations. I had said that I think we recommend against the use > of non-free services like Github but do not forbid their use. > Ian disagreed with this recommendation. > > I responded [2] noting that around 7% of the packages with a vcs-git in > unstable are hosted on Github. > > Ian said [3] that he was confident if we had a GR to forbid use of services > like Github it would pass. > > He proposed the following text for such a GR. > > I think such a discussion is better on -project. Thanks. > > [1]: > > https://lists.debian.org/msgid-search/23927.51367.848949.15...@chiark.greenend.org.uk > [2]: https://lists.debian.org/msgid-search/tslwoedy93e.fsf...@suchdamage.org > [3]: > > https://lists.debian.org/msgid-search/23930.17192.131171.455...@chiark.greenend.org.uk > > > Subject: Free Software Needs Free Tools > > No Debian contributor should be expected or encouraged, when working > to improve Debian, to use non-free tools. That applies to any tool, also free ones. > This includes proprietary > web services. And free 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. Then maintainers could remove them as a workaround. > > 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. Our upstreams are free to use what they want. Note that salsa.d.o is a legal risk. When a contributor uploads non-distributable software, then Debian is in fact redistributing it immediately. Should we promote Github? :-) Cheers, Bart
Re: Debian and Non-Free Services
On Thu, Sep 12, 2019 at 10:37:58PM +, Dr. Bas Wijnen wrote: > > I would not like to make cooperation with upstream more complicated. > > I agree with that. However, I'm not sure if it would make it harder. How does > this cooperation work, where you need your packaging to be on the same host as > upstream? It's sometimes easier to send patches to upstream if you can just send them a pull request. In fact, one of my upstreams (ola) has told me repeatedly that they prefer that. It's easier to send them a pull request if your code is on the same platform as theirs. However, using their platform does not require that you *only* use their platform. My ola repository is on github[1], but also on salsa[2]. [1] https://github.com/yoe/ola [2] https://salsa.debian.org/wouter/ola -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: Debian and Non-Free Services
Le 13 septembre 2019 00:54:47 GMT+02:00, Yao Wei a écrit : >On Thu, Sep 12, 2019 at 10:43:59PM +0200, Pierre-Elliott Bécue wrote: >> Living up to our own principles is a noble thing, but I'm not keen on >> supporting such a GR as I think the drawbacks outweight the benefits >for >> the project. > >Does this also imply we are reverting the GR on non-free sections? > >https://www.debian.org/vote/2004/vote_002 > >Yao Wei I have a clear doubt about your understanding of my email. Can you develop your point ? Thanks. -- PEB (from my phone)
Re: Debian and Non-Free Services
Sam Hartman writes ("Debian and Non-Free Services"):
> I'm trying to move a thread from -devel.
>
> Ian Jackson responded [1] to part of a consensus discussion on Git
> recommendations. I had said that I think we recommend against the use
> of non-free services like Github but do not forbid their use.
> Ian disagreed with this recommendation.
Sam, from this thread, it seems very likely[1] that you were right
about where Debian's consensus was, and that I was wrong.
> He proposed the following text for such a GR.
Also Enrico Zini sent a couple of messages where he strongly objected
to this escalation by me. IME Enrico Zini is usually right. I should
have listened to him more carefully the first time.
For my own part, I'm going to drop this suggestion now. I still don't
agree with the apparent project consensus but I want to spend my
energy on something more constructive.
Ian.
[1] Even allowing for the fact that mailing list threads are not a
very reliable way to judge the project's overall views.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Debian and Non-Free Services
On 19-09-12 20 h 35, Scott Kitterman wrote: > > > On September 12, 2019 5:30:24 PM UTC, Sam Hartman wrote: >> >> I'm trying to move a thread from -devel. >> >> Ian Jackson responded [1] to part of a consensus discussion on Git >> recommendations. I had said that I think we recommend against the use >> of non-free services like Github but do not forbid their use. >> Ian disagreed with this recommendation. >> >> I responded [2] noting that around 7% of the packages with a vcs-git in >> unstable are hosted on Github. >> >> Ian said [3] that he was confident if we had a GR to forbid use of >> services >> like Github it would pass. >> >> He proposed the following text for such a GR. >> >> I think such a discussion is better on -project. >> >> [1]: >> https://lists.debian.org/msgid-search/23927.51367.848949.15...@chiark.greenend.org.uk >> [2]: >> https://lists.debian.org/msgid-search/tslwoedy93e.fsf...@suchdamage.org >> [3]: >> https://lists.debian.org/msgid-search/23930.17192.131171.455...@chiark.greenend.org.uk >> >> >> 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. >> >> 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. > > 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 While I do sympathise with the idea of not having Debian package on Github, I have to agree with Scott here. I think I would end up voting against such a GR because the use of Git isn't mandatory. If we already had a GR enforcing the use of Git, I think it would only make sense to make the use of salsa.debian.org mandatory. It seems we aren't there yet though. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
Re: Debian and Non-Free Services
On September 14, 2019 12:29:19 AM GMT+09:00, Scott Kitterman wrote: >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. +100 Best comment till now. "Crusade" is the word I should have used in other occasions. Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: Debian and Non-Free Services
On Friday, September 13, 2019 10:52:37 AM EDT Sam Hartman wrote: > > "MJ" == MJ Ray 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
Re: Debian and Non-Free Services
> "MJ" == MJ Ray 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
Re: Debian and Non-Free Services
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
Re: Debian and Non-Free Services
Bas Wijnen wrote: > note that the proposal is not to say "our users must not be allowed to use > github". It's "our developers must not be allowed to force contributors to > use github". Scott Kitterman wrote: > 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. I believe it may be useful to think along the "preferred form for modifications" clause of the GPL. Which is the "preferred form for modifications" of Debian packaging? As I understand policy, currently it's the source package. If that doesn't reflect actual practice, that might be good reason to change policy. In any case, I'd always expect the "preferred form" of all packages to be available on the Debian infrastructure: one must not depend on any external services, free or not, in order to be able to obtain it. So, if Git-based packaging becomes the norm, it is my understanding that the master Git repo of all packages must be hosted on Debian servers. Clearly, maintainers can still host their own working copy wherever they would like to, and there's no requirement to make it publicly accessible through a free service, or at all. Gerardo
Re: Debian and Non-Free Services
On Thu, Sep 12, 2019 at 01:30:24PM -0400, Sam Hartman wrote: > Subject: Free Software Needs Free Tools ZOMG. IMO one of the less good ideas brought to this list. I will refrain from further comments for everyones benefit, Ansgar brought up the most relevant objections already. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Debian and Non-Free Services
чт, 12 сент. 2019 г. в 20:30, Sam Hartman : > 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
Re: Debian and Non-Free Services
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
Re: Debian and Non-Free Services
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
Re: Debian and Non-Free Services
"Dr. Bas Wijnen" writes: > On Thu, Sep 12, 2019 at 07:49:26PM +0200, Ansgar 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. >> >> Does this include: >> >> - non-free firmware on Debian hardware, >> - non-free software for interacting with hardware, >> - non-free backup systems? > > You may be correct. In that case, this GR, if passed, declares that we want to > change that. Is that controversial? The GR forbids using any of these. That is not helpful. As far as I know there is no mainstream hardware that doesn't require non-free firmware; using non-mainstream hardware is possible, but has other problems. >> > This includes proprietary >> > web services. We will ensure this, insofar as it is within Debian's >> > collective control. >> >> Does this include use of proprietary CDN networks, DNS services, cloud >> services (such as VMs or storage) or social network services (Twitter)? >> Again, you probably cannot avoid them when contributing to relevant >> parts of the project. > > Yes, it should mean that. Again, it doesn't mean people are not allowed to use > them. It means that people who don't want to use them can still contribute to > Debian. So for example, it would not be allowed to ignore the bts and only > accept bug reports through Twitter. So assume I want to avoid using non-free DNS and CDN services, but still contribute to Debian. How should that work as long as Debian uses these services? How should one contact people using non-free mail services? (mailto:non-free is probably not better than https://non-free...) Of course Debian can stop using CDN services and provide a worse experience for users, but why? Debian's goal is not to build and operate a free CDN service... Ansgar
Re: Debian and Non-Free Services
Hi! On Fri, 2019-09-13 at 00:35:23 +, Scott Kitterman wrote: > On September 12, 2019 5:30:24 PM UTC, Sam Hartman wrote: > >Ian said [3] that he was confident if we had a GR to forbid use of > >services > > like Github it would pass. I very much doubt that, TBH, but… > >He proposed the following text for such a GR. > > 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. > > > > 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. > > 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. Exactly. This GR seems just very misguided to me. With git being distributed you could even just pull once and push elsewhere, or ask someone else to do that. But even then we don't really require any git repos, one can just «apt source» stuff. I'm also not seeing how you can distinguish github from people's own servers where you get no source for the software used, nor setup instructions to replicate, etc, etc. In most cases you might not even know what software is being used at all underneath! This would end up with people delisting repos from the fields, while still using them. Which personally I don't see as a huge loss, but I assume Ian does? To give some context, I was one of the so called "hard-liners" in the vote to punt non-free from Debian. I think that's still an ideal I'd like we pursued, even though I think the firmware case is a tolerable exception (given that you end up running these blobs anyway even if you do not update them). To me that leaves the non-free documentation, which while bad, at least does not execute anything. So, non-free tools that no one is forced to use are unnaceptable, but documentation essential to do much work in Debian is not? Many GNU packages have its entire docs in the non-free section (which I fully agree with). In my mind a proper GR w/o the selective filtering would imply we need to switch away too from most of those GNU packages, starting with gcc, gdb, binutils, make, tar, bison, gawk, etc. Thanks, Guillem
Re: Debian and Non-Free Services
On September 12, 2019 5:30:24 PM UTC, Sam Hartman wrote: > >I'm trying to move a thread from -devel. > >Ian Jackson responded [1] to part of a consensus discussion on Git > recommendations. I had said that I think we recommend against the use > of non-free services like Github but do not forbid their use. > Ian disagreed with this recommendation. > >I responded [2] noting that around 7% of the packages with a vcs-git in > unstable are hosted on Github. > >Ian said [3] that he was confident if we had a GR to forbid use of >services > like Github it would pass. > >He proposed the following text for such a GR. > >I think such a discussion is better on -project. > > [1]: >https://lists.debian.org/msgid-search/23927.51367.848949.15...@chiark.greenend.org.uk >[2]: >https://lists.debian.org/msgid-search/tslwoedy93e.fsf...@suchdamage.org > [3]: >https://lists.debian.org/msgid-search/23930.17192.131171.455...@chiark.greenend.org.uk > > > 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. > > 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. 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. Scott K
Re: Debian and Non-Free Services
On Thu, 12 Sep 2019, Ansgar wrote: > That would just lead to packages using these to no longer including the > Vcs-* fields... There are some valid reasons to host packages on Indeed, that will happen. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: Debian and Non-Free Services
On Thu, Sep 12, 2019 at 10:43:59PM +0200, Pierre-Elliott Bécue wrote: > Living up to our own principles is a noble thing, but I'm not keen on > supporting such a GR as I think the drawbacks outweight the benefits for > the project. Does this also imply we are reverting the GR on non-free sections? https://www.debian.org/vote/2004/vote_002 Yao Wei signature.asc Description: PGP signature
Re: Debian and Non-Free Services
On Thu, Sep 12, 2019 at 07:49:26PM +0200, Ansgar 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. > > Does this include: > > - non-free firmware on Debian hardware, > - non-free software for interacting with hardware, > - non-free backup systems? As far as I'm concerned, yes. But note that the proposal is not to say "our users must not be allowed to use github". It's "our developers must not be allowed to force contributors to use github". I think that is very reasonable, at least for tools (including services) where free alternatives are available. > AFAIK Debian uses all of these and you are probably expected to deal > with them when contributing to relevant parts in Debian. You may be correct. In that case, this GR, if passed, declares that we want to change that. Is that controversial? > > This includes proprietary > > web services. We will ensure this, insofar as it is within Debian's > > collective control. > > Does this include use of proprietary CDN networks, DNS services, cloud > services (such as VMs or storage) or social network services (Twitter)? > Again, you probably cannot avoid them when contributing to relevant > parts of the project. Yes, it should mean that. Again, it doesn't mean people are not allowed to use them. It means that people who don't want to use them can still contribute to Debian. So for example, it would not be allowed to ignore the bts and only accept bug reports through Twitter. > > 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. > > That would just lead to packages using these to no longer including the > Vcs-* fields... There are some valid reasons to host packages on > services such as GitLab or GitHub such as when they are hosted there as > part of the upstream project and/or for better cooperation with > upstream. > > I would not like to make cooperation with upstream more complicated. I agree with that. However, I'm not sure if it would make it harder. How does this cooperation work, where you need your packaging to be on the same host as upstream? I usually download their release and work on that. It really doesn't matter where I do that. Of course I report issues upstream in their issue tracker, but that doesn't need to be on the host where my packaging is. On Thu, Sep 12, 2019 at 10:19:46PM +0200, Marc Haber wrote: > Count my vote in as a firm "No". This is going the same road as the > "editorial changes" two decades ago, the first occasion where my > motivation in Debian was damaged. The problem with that GR was that at the time of voting, people did not realize what they were deciding. With this GR that won't be the case, if people like you explain what the problem is. So I don't believe it is a similar situation. But please, in order to avoid the problem, elaborate on what the problem with this proposal is. Thanks, Bas signature.asc Description: PGP signature
Re: Debian and Non-Free Services
Le jeudi 12 septembre 2019 à 13:30:24-0400, Sam Hartman a écrit : > I'm trying to move a thread from -devel. > > Ian Jackson responded [1] to part of a consensus discussion on Git > recommendations. I had said that I think we recommend against the use > of non-free services like Github but do not forbid their use. > Ian disagreed with this recommendation. > > I responded [2] noting that around 7% of the packages with a vcs-git in > unstable are hosted on Github. > > Ian said [3] that he was confident if we had a GR to forbid use of services > like Github it would pass. > > He proposed the following text for such a GR. > > I think such a discussion is better on -project. > > [1]: > > https://lists.debian.org/msgid-search/23927.51367.848949.15...@chiark.greenend.org.uk > [2]: https://lists.debian.org/msgid-search/tslwoedy93e.fsf...@suchdamage.org > [3]: > > https://lists.debian.org/msgid-search/23930.17192.131171.455...@chiark.greenend.org.uk > > > 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. > > 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. While I'm sensible to the motivations behind this idea, in my opinion¬: 1. Restricting the platform where people would work on packaging stuff is more prone do deprive us from workforce than achieve any good. This also would complicate the interactions with our upstreams; 2. Doing so by forbidding to see these in a metadata field looks like mere wishful thinking to me; 3. Promoting and defending Free Software doesn't mean refusing to rely or touch any non-free software. We touch it each and every day; 4. This kind of GR and the potential decision would just ostracize ourselves. Living up to our own principles is a noble thing, but I'm not keen on supporting such a GR as I think the drawbacks outweight the benefits for the project. I'm of course eager to change my mind if I missed something. Best, -- Pierre-Elliott Bécue signature.asc Description: PGP signature
Re: Debian and Non-Free Services
On Thu, Sep 12, 2019 at 01:30:24PM -0400, Sam Hartman wrote: > He proposed the following text for such a GR. > > I think such a discussion is better on -project. > > [1]: > > https://lists.debian.org/msgid-search/23927.51367.848949.15...@chiark.greenend.org.uk > [2]: https://lists.debian.org/msgid-search/tslwoedy93e.fsf...@suchdamage.org > [3]: > > https://lists.debian.org/msgid-search/23930.17192.131171.455...@chiark.greenend.org.uk > > > Subject: Free Software Needs Free Tools Count my vote in as a firm "No". This is going the same road as the "editorial changes" two decades ago, the first occasion where my motivation in Debian was damaged. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Debian and Non-Free Services
> Subject: Free Software Needs Free Tools > > No Debian contributor should be expected or encouraged, when working > to improve Debian, to use non-free tools. Does this include: - non-free firmware on Debian hardware, - non-free software for interacting with hardware, - non-free backup systems? AFAIK Debian uses all of these and you are probably expected to deal with them when contributing to relevant parts in Debian. > This includes proprietary > web services. We will ensure this, insofar as it is within Debian's > collective control. Does this include use of proprietary CDN networks, DNS services, cloud services (such as VMs or storage) or social network services (Twitter)? Again, you probably cannot avoid them when contributing to relevant parts of the project. > 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. That would just lead to packages using these to no longer including the Vcs-* fields... There are some valid reasons to host packages on services such as GitLab or GitHub such as when they are hosted there as part of the upstream project and/or for better cooperation with upstream. I would not like to make cooperation with upstream more complicated. Ansgar
Debian and Non-Free Services
I'm trying to move a thread from -devel. Ian Jackson responded [1] to part of a consensus discussion on Git recommendations. I had said that I think we recommend against the use of non-free services like Github but do not forbid their use. Ian disagreed with this recommendation. I responded [2] noting that around 7% of the packages with a vcs-git in unstable are hosted on Github. Ian said [3] that he was confident if we had a GR to forbid use of services like Github it would pass. He proposed the following text for such a GR. I think such a discussion is better on -project. [1]: https://lists.debian.org/msgid-search/23927.51367.848949.15...@chiark.greenend.org.uk [2]: https://lists.debian.org/msgid-search/tslwoedy93e.fsf...@suchdamage.org [3]: https://lists.debian.org/msgid-search/23930.17192.131171.455...@chiark.greenend.org.uk 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. 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.
