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 <ijack...@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.