Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
On Saturday, September 14, 2019 6:01:24 PM EDT Thomas Goirand wrote:
> On 9/14/19 6:59 AM, Balasankar "Balu" C wrote:
> > But it shouldn't matter to the project that I do my packaging work in
> > GitLab.com or GitHub.com because as far as Debian is concerned, as long
> > as others can contribute without having an account in that service - I
> > should not be forbidden using them. That is, if I come in and say "I
> > won't accept any patches submitted over BTS, but only GitHub PRs", the
> > project has every right to kick the package out of Debian or fork it.
> > But as long as I continue supporting people using BTS, I should be fine
> > using whatever I want as my primary platform.
>
> Could you explain why you'd have VCS fields then, if not to advertise
> what the addres of your Git? Isn't this an invitation to use the
> platform you're pointing at, as a mean to modify your package?
>
> > So will the GR be
> > "You must not do any sort of contribution to Debian using non-free
> > software/hardware"
> >
> > or
> >
> > "You can use anything you want to contribute to Debian, but there should
> > be a way for other people to contribute to your work in Debian without
> > compromising on their freedom" ? (This translates to my words in the
> > beginning of this reply - patches over BTS must not be rejected by a
> > maintainer)
>
> Of course, the later. I don't care if a contributor is using Debian in a
> VM running on Windows, as long as he/she doesn't force me to do the
> same. That's the same spirit with using a non-free Git platform.
What you proposed sounded a lot like the former to me and apparently others.
> 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.
The Vcs-foo is there as an aid to finding additional information about the
package. There's no requirement to deal with it when you are NMUing. NMU
diffs go to the BTS. End of story.
There's nothing that requires you to interact with a VCS repository that you
don't care to.
If a maintainer is non-responsive to bugs/patches in the BTS, it doesn't
matter where the Git repository is.
Scott K
Reply to: