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

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



On Sun, Sep 15, 2019 at 12:01:24AM +0200, Thomas Goirand wrote:
> It is a real life experience that I had to touch horribly maintained
> packages by unknown contributors, with Vcs-Git:
> https://github.com/<foo>/<bar>, missing commits not matching the
> archive, and no response from the maintainer to the BTS (even for RC
> bugs). The last occurrence of this was pyroute2, which I pushed into the
> DPMT (and still no reply from that past maintainer). I hate seeing this,
> and don't want this anymore, though it happens again, and again, and
> again. So, the only way to get out of this is enforcement, like it or not..

I resent the implication that Vcs-Git: pointing to github.com implies
badly maintained packages.

Badly maintained packages can also have a Vcs-Git: pointing to
gitlab.com or salsa.d.o. Same for ignored bugs in the BTS, unresponsive
maintainers, or incomplete git repositories. None of this has anything
to do with the git hosting service in use.

Enforcing things can help in avoiding those issues, but then make sure
you enforce the correct thing. "Stuff must not point to github.com" is
not that.

Instead, we could make it policy that:
- incomplete git repositories should be considered an RC bug
- RC bugs in the BTS will get your package removed from Debian
- Badly maintained packages will result in RC bugs
- unresponsive packagers will get their packages removed from them.

Luckily we already do most of those.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard


Reply to: