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

Re: Git Packaging Round 2: When to Salsa




On September 10, 2019 10:12:39 AM UTC, Sam Hartman <hartmans@debian.org> wrote:
>>>>>> "Scott" == Scott Kitterman <debian@kitterman.com> writes:
>
>
>    Scott> I don't think your alleged works poorly for using your own
>    Scott> namespace are real problems.
>
>I would be a lot happier if your message was phrased in terms of
>discussing which trade off you prefer.
>It's clear from past discussion that people are concerned about these
>issues.
>I hear you as saying that you value other things more .

I value maintainers having a sense of responsibility for their packages.  I think that we've pushed the benefits of loosening maintainer control (and there are certainly benefits) about as far as we can without risking it becoming meaningless.  If everyone is responsible for something, what that really means is that no one is.

I think people feeling like someone else will handle things is a much bigger problem than losing ephemera like historical merge requests.

>    Scott> Since git has no single central
>   Scott> repository moving is as simple as a clone and then push it to
>    Scott> the new location.  If there are multiple instances of a
>   Scott> package on salsa (which can happen for any number of reasons)
>    Scott> the "official" one is the one the Vcs-* point to.
>
>I do believe this viewpoint has been considered in the discussion.
>I don't have the counter-arguments at hand that have been made.  So
>here
>I'm responding with my own opinion rather than trying to make a call
>based on past discussions.
>
>* There's a lot in Gitlab beyond just the repo.  Cloning a repo doesn't
>  clone merge requests, issues, wiki, pipelines, or artifacts among
>  others.
>
>* It doesn't clone access control information
>
>* There is a significant coordination/transition cost in changing names
>  even when no information is lost.
>
>* There's value in stability of names.  As an example does everyone
>look
>  at vcs-* out of unstable rather than say testing or stable?
>
>I suspect you have considered most if not all of the above.  I do hear
>you as saying you value other things (which I think you have not yet
>specified) more.
>
>However, when you say that a concern is not valid, it's easy to read
>that as saying that it is unreasonable to value fixing that concern.  I
>disagree strongly: I think a technical concern with trade offs on both
>sides has been articulated.

See above.  Personally, I usually end up looking at tracker.d.o which uses the most recent version.

While I think having a common Debian namespace for packages is fine for people that want it, I think the arguments for it are overstated.  We had collab-maint on alioth, but it was harder to deal with alternatives then.  Let's not make present virtue out of past necessity.

I don't agree with the "people are used to it" argument either.  On platforms like GitHub there's a working assumption that only regular commiters can directly commit.  Everyone else uses pull requests.    Now that we are on gitlab, a common namespace is far less beneficial than it used to be.

Scott K


Reply to: