Dominik George <naturesha...@debian.org> writes: > Well, the consequence of my proposal, if we take it further, would be:
> If a maintainer lists their VCS in the source package, then they need to > accept people using it. And if they accept people using it, they must > ensure that everyone can do so under the same conditions. > Maintainers of course MUST always accept bugs and patches (accept as in > receive and consider, not merge into their package) through the BTS. We > have this provision in place, and I have no intentions to change that. So I want to say up front that personally I think the Debian packaging for every package in Debian should ideally have an existence on Salsa and all maintainers should set up their personal Salsa configurations so that they receive merge request notifications and other communication from it, even if they primarily do development elsewhere. This is what I did when this discussion started a while back, even in cases where my packages have dual (or more) existences elsewhere, and I've never had trouble with it. One of the significant advantages of Git as a technology (which is now by far the most common way to maintain Debian packages) is that it's fairly trivial to allow the repository to live in multiple places. But my concern with this approach to trying to push people in that direction is that it's starting to sound to me a bit like the FSF's failed effort to attempt to get free software projects to refuse to ever mention or point to non-free software. Debian rejected this communication strategy, to the great ire of the FSF, and quite rightfully so. Free software is a broad community with a wide range of opinions about both what ideal role free and non-free software should play in our computing lives and about what practical steps should be taken to achieve those ends. Some Debian developers are free software activists; some are not, and simply want to work together on a shared distribution maintained using free software principles. There is widespread disagreement within that community about the appropriate role of GitHub. I'm saying this not to restart that conversation, which I don't think will be that productive, but only to acknowledge that diversity in our community. The way Debian has dealt with this historically is to say that the *Debian* part of your work needs to follow our free software principles, and we stay out of the rest of your business. I respect that your proposal is trying to stick to that line and is only talking about the Debian packaging. But I'm worried that it's getting close to the line that the FSF crossed, in which they tried to tell people that they weren't permitted to talk about certain tools because they were ideologically incorrect. I agree with all of your points about the importance of allowing contributions from the full range of Debian contributors and not forcing people to create GitHub accounts (which they may not even be able to do) in order to contribute to Debian packaging. I would strongly encourage everyone using Git to maintain Debian packages to mirror that repository on Salsa and accept contributions there so that Debian can continue to move towards standardizing a contribution flow. But if the primary development is happening on GitHub and that's the first place that any changes are pushed to and that's the current state of the packaging, I'm dubious the merits of telling people not to point to GitHub outweigh the frustrations. I think there are two very important points here that, were either of them different, would probably change my mind: * GitHub allows anonymous Git cloning and anonymous browsing of the repository without creating an account. * The Vcs-Git and Vcs-Browser fields have never promised that you can submit pull requests, file issues, or do any form of interactive development at those sites. They *only* point to a possibly read-only Git repository. For many years, in all of my packages, they pointed to a gitweb instance I run myself that literally no one else has access to. In other words, GitHub fulfills the narrow promise of Vcs-Git and Vcs-Browser: here is the current read-only packaging repository, available to everyone. I completely agree with you that it's not appropriate for a Debian package maintainer to refuse to consider submissions that don't go through GitHub. But we already address that by relying on patches to the BTS as the common denominator, and provide Salsa for people who don't like patches and prefer merge requests. If someone is telling all bug submitters to their package that they will only look at submissions via GitHub, this makes me sad and I think the project has some grounds to ask them to stop doing that. But I don't think that's the same as your proposal. If we as a project are ready to move forward towards a world in which the project is standardizing on a contribution flow, or even on a VCS, I would be delighted. That would naturally lead towards requiring all projects be in Salsa or some successor, and I'm all in favor. But until such time as we're willing to make that decision, I'm dubious about singling out GitHub as verboten when we allow Vcs-* fields to point to read-only Git repositories with a subset of the functionality that GitHub provides to people without an account. In other words, if we're going to require Vcs-* point to an actual forge and not just a VCS repository, great, but we're not there yet. I recognize your point about how GitHub excludes certain users and I in no way mean to defend this. This is a real feature of Salsa, even more than I was previously aware. But I also don't think this is a strong enough argument on which to rest this proposal. The BTS interaction is also exclusive in the sense that not everyone's email is going to get through; some of it is going to be filtered or rejected for all sorts of reasons. Communication is lossy. I completely agree that we should have fallbacks that are as universal as possible, and that we should not be telling people they are required to use GitHub. But this doesn't feel like the right hammer to me. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
