Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
Hi,
On 14/9/19 4:21 AM, Thomas Goirand wrote:
> On 9/12/19 2:47 PM, Sam Hartman wrote:
>> 1) there are significant problems we'd run into if we forbid non-free tools in
>> Debian work
>
> Sorry, WHAAAT ? That's shocking to read this from the DPL.
> Are you sure you didn't do a mistake in this sentence?
>
> There's absolutely no problem within the Debian project to forbid using
> non-free software.
Debian project using non-free software for day-to-day functioning is
different that Debian contributors using non-free software.
If Debian project was using GitHub Enterprise or GitLab Enterprise
Edition for hosting all the source code and demanded all packages in
Debian to use that for development, that is an issue.
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.
Until Salsa repo is a first class citizen (that is, something
unavoidable and a mandatory requirement) in Debian development , we
can't mandate on using that. AFAIK, BTS is the official ("official", not
"mandatory") way to develop Debian because it is the only thing
mentioned in policy (I don't know if we explicitly say to use BTS for
everything, but we do mention BTS few times in the policy document).
That's what I've signed-up for (ie: "debian will
> remain 100% free", aka the FIRST LINE of the social contract), and what
> I want, and I'm sure the vast majority of DDs agree.
Yes, what Debian project uses and produces must be 100% free. But I
won't enforce anyone to use Salsa unless there is a project-wide
consensus that packaging of every package must happen in <Salsa>
(replace <Salsa> with any service).
And personally, I am not sure how such a decision will impact the Project.
>
> In the long run, there's going to be significant problems if we open
> then Pandora box of using non-free stuff to build Debian.
Agree with this, if it is referring to the technical meaning of "build"
(a package depending on a non-free library to be compiled), not the
general one (that is "gadgets or devices or tools a person uses to do
packaging work).
> Indeed, I'm being increasingly frustrated with what's going on in Salsa
> in general, and especially when it comes to using Google's
> infrastructure. We *must* get out of this. If going through a GR helps
> Salsa admins to realize a point of view that I believe I share with a
> large amount of people within Debian, then I'm all for it.
I agree - if we as a Project feels like Salsa is being administered in a
manner we don't prefer, we should clarify it via a GR, and decide how we
can help Salsa admins on this.
>
> On 9/12/19 4:37 PM, Enrico Zini wrote:
>> I see you keep pushing things with a strong cohercive slant rather
>> than working on creating useful and attractive infrastructure to make
>> everyone's work easier.
>
> What exactly do you propose here? The Salsa admins look like not
> accepting more contributors, neither seem open to suggestions. They just
> do "their way". I've countless times wrote to both them and in public
> that I'd love to be involved to make things more free. They also refused
> to use a packaged version of Gitlab even before it was a thing. They
> decided to use Google service, without prior communication about it and
> agreement of the community. When some of us pointed out it wasn't ok, it
> was strongly rejected, despite any possible offer to use something else
> (like Swift storage of other providers).
This feels like a serious problem to me. Could you also share links, please?
> On 9/13/19 9:39 AM, Enrico Zini wrote:
>> Sam showed you how the situation in Debian seems to be different from
>> what you understood, and your response was not to acknowledge, try to
>> understand, and map the current status quo, but to consider of a GR to
>> force the status quo to fit to your expectations.
>
> I very much don't agree on this. If 7% of the packages with VCS fields
> are using Github, we *MUST* do something about it. And that's not just
> to fit Ian's own malicious agenda, or to please him. If this has to go
> through a GR, to make the small minority understand that the vast> majority of us don't agree, then let's do it!
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)
I am very much for the latter. I have my concerns about the former and
how it may impact new comers- but in general I don't object much about
making a specific platform (for now, Salsa?) mandatory for Debian
development. I would also support such a GR, but I would rather make
sure Salsa is administered in a way that the project is happy with.
PS: I do expect friction to happen if we decide on only a specific way
to contribute to Debian - Salsa. It is understandable because if someone
said "You can develop only using BTS and patches sent there", I would
not be on board.
Regards
Balu
Reply to: