Wouter Verhelst <wou...@debian.org> writes: > On Sun, Sep 15, 2019 at 01:16:26AM +0200, Thomas Goirand wrote:
>> However, basically, what you're saying is that, for those who care >> about not using non-free platforms, we should just not do that anymore, >> as it's not required anyway. > No. > If this were about a non-free Subversion hosting service, then yes, I'd > agree. Even if someone were using a non-free Subversion hosting service for their personal convenience in maintaining the package, there's still the fact that we don't mandate that maintainers use *any* particular tools to maintain a package. The source package as uploaded to the archive is the basis of Debian development currently. If someone wants to download the source package, edit it with a text editor, build a new source package, and upload it without ever using a VCS of any kind, they can. Therefore, I think we need to apply an "as-if" rule here. If the impact on the archive is indistinguishable from someone using no tools at all, I'm not seeing what *policy* someone would be violating. We could ask them to not use a Vcs-Svn field pointing to a non-free hosting service on the grounds that it's advertising non-free software (I've never been that fond of the FSF's stance on this sort of thing and am dubious about us adopting it, but there's certainly a defensible argument), but we should be aware that they could just delete the Vcs-Svn field from the source package while changing nothing else about their workflow and they're then entirely compatible with our policies. Taking a step back, what I'm objecting to here is that I think people are implicitly extending the definition of a source package to include the VCS and implicitly assuming that we're going to require people to use a VCS, but are not saying that explicitly. (To be fair, Ian *is* saying that explicitly, which I think makes everything clearer and more straightforward, and lets us have an argument on the merits. But I think the merits of a *requirement*, as opposed to a recommendation, are weak as currently framed, without a bunch more work to use standardized Git branch layouts and facilities for global changes.) We have to decide if the VCS used for maintaining a Debian package is in scope for our policies and procedures or not. Currently, it is not, so telling people what Git hosting service they can use is out of scope in exactly the same way that we don't tell people what text editor they use to change Debian packaging files. If we're going to bring it in scope, this implies a bunch of other things that people may or may not want, which is why we need to talk about it directly. For instance, it implies that we'll have an acceptable list of VCSes. It also raises the question of what we expect to put in that VCS; in other words, how is using a VCS any different than the Debian archive right now? What are we gaining by adding this requirement? If someone made all the changes they wanted to make between uploads as a single commit, would that be acceptable? If they made a lot of separate commits and then did a squash rebase so that all the changes were a single commit, would that be acceptable? And if those are acceptable, note that dgit already reconstructs exactly that sort of Git reopsitory from the archive. So why does the maintainer have to do anything different if dgit is already constructing that archive? What are we trying to accomplish by making policy here? I think people aren't thinking through the implications of making this a requirement rather than a recommendation, and the edge cases that we then create. It feels very knee-jerk: "non-free hosting is bad," without thinking about whether that has any actual implications for the project or for the workflows of other developers. I'm assuming that the project *isn't* trying to go to the extent of telling people they're not allowed to use non-free editors to make changes to their Debian packages. I think people need to consider whether they want to create bugs that are resolvable by just deleting the Vcs-* fields without making any other changes, and if that really achieves anything meaningful for the project. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
