TL;DR: These are only guidelines. You're free to ignore them. So I
think the issue you bring up isn't a big deal in this case.
In more detail:
>>>>> "Theodore" == Theodore Y Ts'o <ty...@mit.edu> writes:
Theodore> One thing that is been left unclear is what does it mean
Theodore> to "use salsa"?
Use Salsa" as a term doesn't seem to appear in the recommendation text.
I'd assume that your evaluation of the recommendation might go like
this:
* No existing team
* Hmm, I'm a Debian developer packaging for debian. So, let's look at
the general recommendation. Wonder along. Get to notes and limitations
and decide probably that you don't want all developers to have push
access because you don't want to force push when you disagree with
changes.
* So you decide that the general recommendation is not for you and get
to the "Packages not on Salsa" recommendation. Perhaps you decide to
mirror to salsa as suggested there.
I'm fairly sure you're already following the rest of the guidelines in
that section.
Theodore> So I could create a Salsa repo for e2fsprogs and add it to
Theodore> the list; but what does that actually mean? What does it
Theodore> mean to have a Vcs-Git line pointing at git.kernel.org
Theodore> versus salsa.debian.org? It surely doesn't mean anything
Theodore> about access rights, whether it's "any random Debian
Theodore> person can check in arbitrary things to the repo ---
Mostly it makes things more consistent about where to find your code for
people thinking more about a lot of Debian packages than about
e2fsprogs.
Does it have huge value? It might some day if we get to a point where
we do require everyone to at least mirror to salsa.
Today it makes it easier for us to do things like that in the future.
Is it worth you doing given how many repos you already have?
Don't know; perhaps you have enough that it is easy. Perhaps adding one
more is more effort and you don't see the point.
Theodore> And suppose I did create a Salsa repo for e2fsprogs, which
Theodore> could be changed by anyone in the debian group. And
Theodore> suppose someone adds something to the git repo which is
Theodore> totally wrong, and which bypassed any kind of code review.
Theodore> No problem! I'd just do a force push and the commit in
Theodore> Salsa would Go Away. Or is that sort of thing frowned
Theodore> upon with having a git repository on Salsa?
I bet we don't have a consensus. I personally wouldn't put a repo that
commonly had master force-pushed in the debian group on Salsa. I
wouldn't mind force-pushing rarely say if I changed branch formats or
there was a significant oops.
I would prefer not to have to develop such a consensus now.
I agree that it's a great thing to converge on in the future.
Theodore> As a result, I'd argue that when we talk about "forcing"
Theodore> people to use Salsa, it's actually kind of underspecified
Theodore> what might be meant by that.
I agree.
But since we're not talking about forcing people to use Salsa, I think
it is OK.
We're giving people best practice guidelines to use as a starting point.
Unlike the dh discussion where there are some behaviors we consider
buggy, these are guidelines you can use if they help you or ignore if
they do not.
I think it's OK to be less specified for such guidelines.
We may get more specific in the future. But I think if we try to do
that all in one step, it will be too big to ever take.
--Sam
