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

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github



>>>>> "Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> writes:


    Ian> No-one should be asked to interact with a non-free service, as
    Ian> part of contributing to Debian.

    Ian> Note I say "no-one should be asked".  It is not enough, for me,
    Ian> for there to be a "plan (b)" route.  Ie, it is not OK for a
    Ian> maintainer to advertise a github repo as preferred, or to ask
    Ian> for PRs on github, even if an alternative or mirror, or Salsa,
    Ian> or the BTS are also advertised.

    Ian> This is for two reasons: firstly, this is a matter of
    Ian> principle.  Our mission is free software.  Free software needs
    Ian> free tools.  We should not be advertising or encouraging the
    Ian> use of non-free tools.

I agree that many people in the project want us to work hard to avoid
encouraging non-free tools.
I agree that's a significant consideration.

    Ian> Secondly, there is a practical problem if a maintainer (even a
    Ian> solo maintainer) chooses to regard a nonfree service as
    Ian> primary.  If another person comes along and wants to help out
    Ian> with that package, they will either have to also tolerate using
    Ian> the nonfree service, or they will have to try to persuade the
    Ian> maintainer to abandon their existing hosting or tools (and
    Ian> maybe the maintainer's existing workflow, if the nonfree tools
    Ian> are significantly different).  For me that is wholly
    Ian> unacceptable.

I agree that this can be a consequence of using non-free tools.
I believe those involved in the discussions around this issue have
considered this consequence.

    >> If the use of a non-free service is preventing an active member
    >> of our community from contributing to a team, the team should
    >> work to find a solution so that member can contribute
    >> effectively.

    Ian> This is no good as an answer.

    Ian> In practice imprecations to a team (or a maintainer) to "find a
    Ian> solution so that a Debian contributor can contribute
    Ian> effectively" will be useless because:

    Ian> (i) Even having to ask this question already makes the new
    Ian> contributor seem awkward, puts them at a social disadvantage,
    Ian> and perhaps annoys people.

    Ian> (ii) We lack workable enforcement mechanisms for this kind of
    Ian> imprecation.  (Because we lack *any* workable enforcement
    Ian> mechanisms to deal with obstructive maintainer behaviours.)

    Ian> (iii) Even if everyone has good will, and or even if we had
    Ian> excellent and proportionate and swift enforcement mechanism,
    Ian> there will inevitably be a delay and hassle and friction.

I agree that these are problems you can run into.

    Ian> ...
    >> Using non-free services for Debian packaging is not recommended
    >> but is permitted.

    Ian> I strongly disagree with this, or at least, with what seems to
    Ian> me to be the obvious implication.  It is also contrary to our
    Ian> current practice.

Unfortunately, I believe you are in the rough when judging rough
consensus on this issue.

This was discussed fairly recently on debian-project; my take is that
Thomas Goirand represented a position roughly the same as your own.
My reading of that discussion is that:

1) there are significant problems we'd run into if we forbid  non-free tools in
Debian work

2) There was not sufficient support in that discussion to do so anyway

3) There are significant problems that come up when non-free tools are
used.  The problems enumerated were similar to the problems you describe
above.

More over your claim that this is not our current practice runs counter
to facts. Of the 26,480 packages in my unstable sources with a vcs-git,
1836 are on github.  7% seems much more consistent to me with "NOT
Recommended" than "forbidden."

I think you would take exception if I said that dgit (940 packages in my
unstable sources--about half the github count) ran counter to current
practice. Yes, that is comparing apples to oranges on a number of
levels.  My point is that there is a significant fraction of our
developers who do use github and that it seems to be a current practice.

That said, I'm really confused that your message didn't get any response
before now.  Considering how sharp some of the responses were on
-project, I don't know how to take this.  Were people not responding
because the -project discussion was so recent, they didn't see a need to
rehash it?  Were people not responding because -devel has a very
different audience and everyone here agrees with you?

In terms of next steps.  I'd recommend that you read the -project
discussion.  Your arguments here are not responsive to several of the
counters brought up in that discussion.  Obviously you may disagree with
the trade offs expressed, but it would be valuable for you to consider
the points made in that discussion.  Even so, based on that discussion
and the active use of github, my take is that we do not have a rough
consensus to forbid non-free services.  In addition, there are
substantial unaddressed concerns that would need a response before we
could have an informed rough consensus to forbid non-free services even
if we had sufficient support.

Even if there is not rough consensus to forbid non-free services, I'd
welcome help documenting the concerns that can come up.

--Sam

Attachment: signature.asc
Description: PGP signature


Reply to: