Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
Wouter Verhelst <wouter@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: