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
Attachment:
signature.asc
Description: PGP signature