Re: Git Packaging Round 2: When to Salsa
Sam Hartman writes ("Git Packaging Round 2: When to Salsa"):
> Discussion Comments
> -------------------
...
> I realize that not everyone wants all developers to have push access to
> their packages. If you have a firm idea about that, then this
> recommendation is not for you. I also realize that by starting by
> recommending the debian group I'm recommending a more permissive
> maintainership model closer to low threshhold NMU than only NMU my
> packages after explicit confirmation. I think that the dh discussion
> supports the conclusion that we are OK with that as a project *as a
> recommendation*. If a maintainer doesn't like that level of openness,
> that's fine. My take though is that when recommending what to do to
> people who do not have preconceived ideas, more open policies like the
> debian group and low threshhold NMUs are in alignment with the project.
I absolutely have no problem with recommending this as a practice to
the individual maintainer who doesn't know better. However, for this
practice to be useful:
1. The maintainer's git repository branch format must be documented.
Otherwise another contributor has to guess. This could be done either
by doing maintainer uploads with dgit (since recent versions of dgit
include the maintainer branch format information in the git tags), or
perhaps by writing something in README.source.
2. We need to have a shared understanding of when people may push to
branches in the debian/ repository. I think you are proposing that
the answer be "if you do an NMU". I would support this but it is a
change to current practice. We also need to understand how this
relates to the recommendation to NMU to DELAYED.
3. The answers to (1) and (2) need to be documented.
I would like to suggest another possible widening of when to push to a
branch in the debian group on salsa: "if you would do an NMU, but for
some reason an actual upload is not desirable right now". Examples
could include packages owned by QA, if a maintainer invites you to
make a change, if a bug needs fixing but for transition or migration
or similar release management reasons it is not a good time for an
upload.
> I realize that a number of people choose not to use Salsa. Reasons have
> included:
...
> * Wanting to use a platform less under the control of a small number of
> administrators than Salsa
You are missing one: some people think the software behind Salsa is
not Free enough.
> Non-Free Services
> -----------------
...
> Using non-free services for Debian packaging is not recommended but is
> permitted.
I strongly disagree with this, or at least, with what seems to me to
be the obvious implication. It is also contrary to our current
practice.
No-one should be asked to interact with a non-free service, as part of
contributing to Debian.
Note I say "no-one should be asked". It is not enough, for me, for
there to be a "plan (b)" route. Ie, it is not OK for a maintainer to
advertise a github repo as preferred, or to ask for PRs on github,
even if an alternative or mirror, or Salsa, or the BTS are also
advertised.
This is for two reasons: firstly, this is a matter of principle. Our
mission is free software. Free software needs free tools. We should
not be advertising or encouraging the use of non-free tools.
Secondly, there is a practical problem if a maintainer (even a solo
maintainer) chooses to regard a nonfree service as primary. If
another person comes along and wants to help out with that package,
they will either have to also tolerate using the nonfree service, or
they will have to try to persuade the maintainer to abandon their
existing hosting or tools (and maybe the maintainer's existing
workflow, if the nonfree tools are significantly different). For me
that is wholly unacceptable.
> 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.
This is no good as an answer.
In practice imprecations to a team (or a maintainer) to "find a
solution so that a Debian contributor can contribute effectively" will
be useless because:
(i) Even having to ask this question already makes the new contributor
seem awkward, puts them at a social disadvantage, and perhaps annoys
people.
(ii) We lack workable enforcement mechanisms for this kind of
imprecation. (Because we lack *any* workable enforcement mechanisms
to deal with obstructive maintainer behaviours.)
(iii) Even if everyone has good will, and or even if we had excellent
and proportionate and swift enforcement mechanism, there will
inevitably be a delay and hassle and friction.
In summary: people who refuse to use nonfree software must be 100%
first class citizens within Debian. Nothing that we do must
disadvantage those people in any way.
> Discussion Comments
> -------------------
>
> The biggest question here is whether we have consensus that people
> should be using Git.
I think it is clear that we have consensus that if you don't know
better, you should be using git.
> 2) Upstreams that use some other VCS than Git. I need more input here.
> Would we prefer that people have Debian only packaging repos? Would we
> prefer that they use athe other VCS? Do we not have enough consensus to
> have a recommendation in this case.
I don't think we have consensus. The options are poor:
- Use a non-git vcs for everything
- Use mixed vcs (Debian packaging-only git, upstream in other vcs)
- Use an other-vcs-to-git importing/tracking tool.
> Account Transitions
> ===================
...
> There's been enough discussion of this issue that it seems like someone
> should take on the task of trying to figure out what we as a project
> want. Solutions might include:
>
> * Procedures that get followed when accounts are closed. We probably
> don't want more effort added to the tasks of NM front desk, MIA or
> DAM. But if additional volunteers stepped forward who wanted to help
> with these transitions, it might make sense to approach things that
> way.
>
> * Changing how Salsa and Debian LDAP interact. This would involve
> figuring out what we want and working with the Salsa admins and DSA.
Another possiblity is:
* Accept that maintainer git repositories may move from one location
to another, as a consequence of changes of maintainer, changes of
maintainer status, or changes of maintainer preferences.
This would be a lot less annoying if the information about where to
find the maintainer's git repository were more easily updated.
Consider how long it is taking to update Vcs-Git.
Note that if uploads are done with dgit, the actual git history
(including the maintainer's history) is in a systematic, discoverable
place, on Debian core infrastructure, and maintained with the same
access control as the archive.
I guess you must know that I think we should recommend that people who
are just starting out should upload with "dgit push[-source]".
> Closing Thoughts
> ================
>
> A couple of issues have been brought up where people objected to the
> project recommending Salsa.
>
> I've considered the following issues:
>
> * Some have objected that Salsa is not sufficiently free. My
> understanding of the argument is that Salsa is running a community
> edition of Gitlab that is generally free, but contains non-DFSG free
> components that we would strip/do strip from the package.
The Salsa maintainers have made it clear that they do not intend to
accept patches from Debian contributors. For me that means that we
are not treating Salsa as free software (!)
I have also heard disturbing rumours about exactly what we are taking
from Gitlab upstream. In particular, I would like the Salsa admins to
confirm that what we are running is something we built from source.
> * Others have objected that we don't run the Gitlab package on Salsa.
> I'll note that many core services do not run packaged code.
I think this objection is unsustainable for the reason you give.
In fact, not running packaged code makes it a lot easier for a service
owner to run the version they want, of their service, because they do
not need root privilege to install a .deb.
> I've considered these issues, and my reading of the discussion is that
> the community is aware of them, but they do not rise to a level where
> they would challenge recommending Salsa.
>
> If you'd like to work on Salsa, including helping Salsa be more free,
> reach out to the Salsa admins and see if they can use your help.
I think that these objections do not rise to the level that we
shouldn't recommend Salsa to people who don't already have an opinion.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: