[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Summary: Git Packaging Round 2 [comments by 11/05/2019]

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 <tytso@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

* 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

* 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
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.


Reply to: