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

[Bernd Zeimetz]

On 9/14/19 12:51 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. 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.

That is bullshit. No modern server hardware runs with free software
only. And even for a lot of laptops/computers you need some non-free
firmware blobs. And if not, you still have the bios, which is - in most
cases - not free software. And you want to have microcode updates. And
firmware updates for your networking/fc hardware. And you want to be
able to manage your server hardware.

Forbidding non-free tools for Debian work makes Debian and supporting
Debian impossible.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

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

[Bernd Zeimetz]

On 9/12/19 6:34 PM, Alf Gaida wrote:> Regarding the workflow and
participation - it might be a problem that> one need an account for
github or other non-free services - it's easy> No account, no
participation, bad luck.

You need an account on salsa.
You need an account on savannah.nongnu.org - which is probably hard to
beat if you are looking for a "free" way to host your software.

Where is the problem?

If you don't want to create an account, pull a git repository and send
patches by email, git has the proper tools to do so.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

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

[Thomas Goirand]

On 9/15/19 1:10 PM, Wouter Verhelst wrote:
> 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//, 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.

What I meant was that both combined is very frustrating.

Thomas Goirand (zigo)

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

[Sam Hartman]

> "Marco" == Marco d'Itri  writes:

Marco> On Sep 16, Sam Hartman  wrote:
>> * Work to understand why people are using Github.  From my past
Marco> For the same reason why most people are using Twitter instead
Marco> of Mastodon: the community and network effect.  This is not a
Marco> technical problem, so it cannot be solved by Debian.

Marco> All my packages are on salsa except for the ones for which I
Marco> am the upstream maintainer too, which I feel benefit more by
Marco> being available on Github.

So, today, Github has less lockin potential because of the design of Git
and because of its role in the community.
I think that effective and easy to use bidirectional mirroring could be
an acceptable solution to your need for upstream collaboration.

--Sam

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

[Marco d'Itri]

On Sep 16, Sam Hartman  wrote:

> * Work to understand why people are using Github.  From my past
For the same reason why most people are using Twitter instead of 
Mastodon: the community and network effect.
This is not a technical problem, so it cannot be solved by Debian.

All my packages are on salsa except for the ones for which I am the 
upstream maintainer too, which I feel benefit more by being available
on Github.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Taking a step back, what I'm objecting to here is that I think
Russ> people are implicitly extending the definition of a source
Russ> package to include the VCS and implicitly assuming that we're
Russ> going to require people to use a VCS, but are not saying that
Russ> explicitly.  (To be fair, Ian *is* saying that explicitly,
Russ> which I think makes everything clearer and more
Russ> straightforward, and lets us have an argument on the merits.
Russ> But I think the merits of a *requirement*, as opposed to a
Russ> recommendation, are weak as currently framed, without a bunch
Russ> more work to use standardized Git branch layouts and
Russ> facilities for global changes.)

Russ> We have to decide if the VCS used for maintaining a Debian
Russ> package is in scope for our policies and procedures or not.
Russ> Currently, it is not, so telling people what Git hosting
Russ> service they can use is out of scope in exactly the same way
Russ> that we don't tell people what text editor they use to change
Russ> Debian packaging files.

With my facilitator hat on.
What I'm hearing is that

* Today we're not making the VCS in scope for requirements, but we are
  for recommendations.  I don't know if that means it is in scope for
  policies and procedures: often policies and procedures include
  recommendations as well as requirements.  I don't think anyone is
  proposing that it be in scope for debian-policy as edited by the
  policy editors.

* A number of people have talked about moving toward the VCS being
  something that very much is in scope for requirements.  Things like
  mandating that work be done in Git and moving toward Git as the
  preferred source format.  I don't think Ian is alone in that eventual
  goal.  So I think it is fair to have that in your mind in these
  discussions as something we might eventually do.  I have not tried to
  judge consensus on whether we're hoping to do that some day: it is not
  immediate enough that judging that consensus would be valuable.  I'll
  note that some people like Scott have spoken against such a change.
  So that might happen some day or it might not.

* I think the concern you raise about people just removing the vcs-*
  fields is a blocking objection to forbidding non-free services.  Which
  is to say even if everyone were supporting the idea of forbidding
  non-free services we'd need to have a better answer to that objection
  than has been presented so far to have an informed consensus.

* But that objection ends up not mattering.  We do not have a rough
  consensus to forbid non-free services.

I'm putting together a blog post on Debian's history with non-free
software and services as part of making Debian.
To spoil that post a bit, here are some things I think people who are
unhappy about the use of Github and other non-free services can do:

* Work to understand why people are using Github.  From my past
  experience developing this sort of understanding works better when not
  combined with strong persuasion.  So given their strongly expressed
  opinion, Thomas and Ian might not be the best choice for actually
  interviewing Github users.

* If gaps are identified try and fill them.  For example if more than
  just Norbert are looking for a platform that is under control of a
  wider group than Debian, perhaps the wider free software community
  could benefit from some free Git service that has well established and
  trusted governance.

* Work on documenting and simplifying bidirectional mirroring between
  Salsa and Github.  Provide tools to make that easy to setup.
  

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

[Russ Allbery]

Wouter Verhelst  writes:
> On Sun, Sep 15, 2019 at 01:16:26AM +0200, Thomas Goirand wrote:

>> However, basically, what you're saying is that, for those who care
>> about not using non-free platforms, we should just not do that anymore,
>> as it's not required anyway.

> No.

> If this were about a non-free Subversion hosting service, then yes, I'd
> agree.

Even if someone were using a non-free Subversion hosting service for their
personal convenience in maintaining the package, there's still the fact
that we don't mandate that maintainers use *any* particular tools to
maintain a package.  The source package as uploaded to the archive is the
basis of Debian development currently.

If someone wants to download the source package, edit it with a text
editor, build a new source package, and upload it without ever using a VCS
of any kind, they can.  Therefore, I think we need to apply an "as-if"
rule here.  If the impact on the archive is indistinguishable from someone
using no tools at all, I'm not seeing what *policy* someone would be
violating.

We could ask them to not use a Vcs-Svn field pointing to a non-free
hosting service on the grounds that it's advertising non-free software
(I've never been that fond of the FSF's stance on this sort of thing and
am dubious about us adopting it, but there's certainly a defensible
argument), but we should be aware that they could just delete the Vcs-Svn
field from the source package while changing nothing else about their
workflow and they're then entirely compatible with our policies.

Taking a step back, what I'm objecting to here is that I think people are
implicitly extending the definition of a source package to include the VCS
and implicitly assuming that we're going to require people to use a VCS,
but are not saying that explicitly.  (To be fair, Ian *is* saying that
explicitly, which I think makes everything clearer and more
straightforward, and lets us have an argument on the merits.  But I think
the merits of a *requirement*, as opposed to a recommendation, are weak as
currently framed, without a bunch more work to use standardized Git branch
layouts and facilities for global changes.)

We have to decide if the VCS used for maintaining a Debian package is in
scope for our policies and procedures or not.  Currently, it is not, so
telling people what Git hosting service they can use is out of scope in
exactly the same way that we don't tell people what text editor they use
to change Debian packaging files.

If we're going to bring it in scope, this implies a bunch of other things
that people may or may not want, which is why we need to talk about it
directly.  For instance, it implies that we'll have an acceptable list of
VCSes.  It also raises the question of what we expect to put in that VCS;
in other words, how is using a VCS any different than the Debian archive
right now?  What are we gaining by adding this requirement?  If someone
made all the changes they wanted to make between uploads as a single
commit, would that be acceptable?  If they made a lot of separate commits
and then did a squash rebase so that all the changes were a single commit,
would that be acceptable?

And if those are acceptable, note that dgit already reconstructs exactly
that sort of Git reopsitory from the archive.  So why does the maintainer
have to do anything different if dgit is already constructing that
archive?  What are we trying to accomplish by making policy here?

I think people aren't thinking through the implications of making this a
requirement rather than a recommendation, and the edge cases that we then
create.  It feels very knee-jerk: "non-free hosting is bad," without
thinking about whether that has any actual implications for the project or
for the workflows of other developers.

I'm assuming that the project *isn't* trying to go to the extent of
telling people they're not allowed to use non-free editors to make changes
to their Debian packages.  I think people need to consider whether they
want to create bugs that are resolvable by just deleting the Vcs-* fields
without making any other changes, and if that really achieves anything
meaningful for the project.

-- 
Russ Allbery (r...@debian.org)   

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

[Balasankar "Balu" C]

Hi,

On 15/9/19 3:31 AM, 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?

My understanding is that it is an additional avenue for people to get
more details about a package, how it is managed, and/or to contribute to
the work. It does not automatically override BTS as a place to file
issues or contribute patches to. That is still there.

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

Thanks for clarifying - from reading your initial mail what I understood
was that you meant the former. I stand corrected in my understanding.

> 
> It is a real life experience that I had to touch horribly maintained
> packages by unknown contributors, with Vcs-Git:
> https://github.com//, missing commits not matching the
> archive, and no response from the maintainer to the BTS (even for RC
> bugs). 

Isn't this why we have an NMU process (for the package and an MIA
process for the maintainer). Personally, I consider Debian archive and
BTS as the single source of truth for any package in Debian - yet.

Regards
Balu

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

[Wouter Verhelst]

On Sun, Sep 15, 2019 at 01:16:26AM +0200, Thomas Goirand wrote:
> On 9/15/19 12:06 AM, Scott Kitterman wrote:
> > There's nothing that requires you to interact with a VCS repository that 
> > you 
> > don't care to.
> 
> But I do care about using Git, and interacting with other DDs using it.

Cool.

> However, basically, what you're saying is that, for those who care about
> not using non-free platforms, we should just not do that anymore, as
> it's not required anyway.

No.

If this were about a non-free Subversion hosting service, then yes, I'd
agree. But we're talking about git here, which is a distributed VCS
service.

If you don't want to deal with a non-free hosting service, you can:

- Clone the git repository.
- Push it to the free git hosting service of your choice.
- Push a branch to that git hosting service with the changes you wish to
  make.
- Use git request-pull to send a pull request to the maintainer.

(Alternatively, if using salsa, for the first two steps you can use the
"mirror repository" feature of GitLab)

> That's simply not fair: I care more about software freedom, and
> therefore, I'd be left aside, not being able to use Git when
> interacting with others.

Except you're not.

The above will require that the maintainer on the non-free hosting
service do some more work, yes; that's correct. However, "git
request-pull" will explain to that maintainer how to do that work, and
it's their own fault for using a non-free service to begin with.

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

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

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

[Wouter Verhelst]

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//, 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

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

[Pirate Praveen]

On 2019, സെപ്റ്റംബർ 15 12:57:08 AM IST, Sean Whitton  
wrote:
>Hello Pirate,
>
>On Sun 15 Sep 2019 at 12:27AM +0530, Pirate Praveen wrote:
>
>> That is not going to happen, instead we need to adapt ourselves to
>> this fast paced development and fasttrack.debian.net is a step in
>that
>> direction.
>
>It's not just a matter of adapting workflows -- without real stable
>releases, however good your workflows are, packaging GitLab and
>administering GitLab installations demands more of people's time than
>it
>would if there were real stable releases.
>
>Real stable releases are freedom-enhancing when they free up people's
>time to work on other stuff.

Well, gitlab is not the only git based collaboration platform out there. I'm 
sure some of the alternatives will have a longer release cycle compatible with 
Debian stable releases. Those who care about it can certainly contribute to 
those and promote them. The fast paced development also means it brings out new 
features faster and apparently many people take that tradeoff currently with 
gitlab (not just Debian, other Free Software projects like gnome, KDE are 
either moved or moving to gitlab).

Also if there is a strong interest in LTS releases, gitlab is Free Software and 
others can maintain backports of security releases.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Alexis Murzeau]

On September 15, 2019 1:20:38 AM GMT+02:00, Scott Kitterman 
 wrote: 
>> Besides this, there's something else I don't understand. How much
>effort
>> is it to use a free software based platform? It's not as if Github
>was
>> so much nicer than Gitlab (at least not anymore). What is it that
>people
>> hate about Gitlab so much, that they feel like they must use some
>> non-free platform, even if they know some of us will hate it?
>
>I don't know.  I don't use GitHub except as needed to support
>collaboration 
>with others that use it.  I think that 7% is too large a number just to
>assume 
>there's not a reason.

Speaking for myself, I'm currently using github as git repository for 
streamlink because salsa wasn't there when I started its packaging, and I was 
already familiar with it.
I could have swithed over to salsa before but didn't. For sure, I don't mind 
about switching now and probably will do.
I consider salsa as a comparable alternative to github functionality wise now, 
with the benefit that the git repo used for package development being internal 
to debian (in constrast to lost VCS of old packages that got lost)

Now that there is salsa, I guess many package could move to it.

Maybe a reason to use github, is travis.ci that can be used with github only 
IIRC. But I'm not using that functionality with debian package repository 
anymore in my case. Salsa gitlab's CI can be an alternative but for me debci is 
sufficient. and I run sbuild before pushing/releasing a version.

-- 
Alexis Murzeau

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

[Thomas Goirand]

On 9/14/19 9:30 PM, Pirate Praveen wrote:
> We have packaged many core build tools like webpack, rollup, gulp, grunt etc 
> which makes it easier to build many JavaScript libraries from source

Thanks a lot for that very useful work!

Thomas

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

[Scott Kitterman]

On Saturday, September 14, 2019 7:16:26 PM EDT Thomas Goirand wrote:
> On 9/15/19 12:06 AM, Scott Kitterman wrote:
> > On Saturday, September 14, 2019 6:01:24 PM EDT Thomas Goirand wrote:
> >> On 9/14/19 6:59 AM, Balasankar "Balu" C wrote:
> >>> 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.
> Indeed. Sorry for this (to you, and to all others that wrongly
> understood what I meant).
> 
> >> It is a real life experience that I had to touch horribly maintained
> >> packages by unknown contributors, with Vcs-Git:
> >> https://github.com//, 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.
> 
> Respectfully: this sounds like a non-sense to me. I completely fail to
> understand the logic behind what you just wrote. As, seemingly, you're
> not the only one with that point or argumentation, I need more
> enlightenment.
> 
> If we aren't supposed to use the VCS fields, why do we even have them at
> all? Shouldn't we just get rid of them completely in Debian then? What's
> the point to advertise about some kind of Git repository, if we're not
> supposed to use them? If you're using Git alone, for yourself only, why
> at all publish the repository then?
> 
> > There's nothing that requires you to interact with a VCS repository that
> > you don't care to.
> 
> But I do care about using Git, and interacting with other DDs using it.
> However, basically, what you're saying is that, for those who care about
> not using non-free platforms, we should just not do that anymore, as
> it's not required anyway. That's simply not fair: I care more about
> software freedom, and therefore, I'd be left aside, not being able to
> use Git when interacting with others.
> 
> Besides this, there's something else I don't understand. How much effort
> is it to use a free software based platform? It's not as if Github was
> so much nicer than Gitlab (at least not anymore). What is it that people
> hate about Gitlab so much, that they feel like they must use some
> non-free platform, even if they know some of us will hate it?

I don't know.  I don't use GitHub except as needed to support collaboration 
with others that use it.  I think that 7% is too large a number just to assume 
there's not a reason.

Also, consider that if we prohibit Vcs-foo that point at non-free services 
like GitHub what the likely result will be.  I suspect that people who are 
using such services are doing it for a reason they consider sufficient (or they 
woulnd't be doint it).  

Given that, I'd expect that the rational response to such a rule would be to 
delet the Vcs-foo from the package and carry on using the non-free service.

How does that help make Debian better?

Scott K

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

[Thomas Goirand]

On 9/15/19 12:06 AM, Scott Kitterman wrote:
> On Saturday, September 14, 2019 6:01:24 PM EDT Thomas Goirand wrote:
>> On 9/14/19 6:59 AM, Balasankar "Balu" C wrote:
>>> 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.

Indeed. Sorry for this (to you, and to all others that wrongly
understood what I meant).

>> It is a real life experience that I had to touch horribly maintained
>> packages by unknown contributors, with Vcs-Git:
>> https://github.com//, 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.

Respectfully: this sounds like a non-sense to me. I completely fail to
understand the logic behind what you just wrote. As, seemingly, you're
not the only one with that point or argumentation, I need more
enlightenment.

If we aren't supposed to use the VCS fields, why do we even have them at
all? Shouldn't we just get rid of them completely in Debian then? What's
the point to advertise about some kind of Git repository, if we're not
supposed to use them? If you're using Git alone, for yourself only, why
at all publish the repository then?

> There's nothing that requires you to interact with a VCS repository that you 
> don't care to.

But I do care about using Git, and interacting with other DDs using it.
However, basically, what you're saying is that, for those who care about
not using non-free platforms, we should just not do that anymore, as
it's not required anyway. That's simply not fair: I care more about
software freedom, and therefore, I'd be left aside, not being able to
use Git when interacting with others.

Besides this, there's something else I don't understand. How much effort
is it to use a free software based platform? It's not as if Github was
so much nicer than Gitlab (at least not anymore). What is it that people
hate about Gitlab so much, that they feel like they must use some
non-free platform, even if they know some of us will hate it?

Cheers,

Thomas Goirand (zigo)

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

[Alf Gaida]

On 15.09.19 00:05, Russ Allbery wrote:

> We have more agreement here, although there are a lot of details hidden in
> what "forcing" really means.  But there's a huge space between "don't
> force other people to use non-free software to contribute to Debian" and
> "forbid using non-free software within the Debian project."
>
> I feel like I can say with a very high degree of confidence that we're not
> going to do the latter.  For instance, we're not going to stop using Intel
> and AMD processors in the Debian project, even though they are full of
> non-free software.  So whatever policy stance you're aiming for here needs
> to be a lot more nuanced than how you're presenting it.
>
Thank you Russ for your insightful words - it's like a beacon in the
night and let me try to trust debian at all more than i do right now. To
be honest about, i have not much trust in anyone, but your posts over
the last decade helped me to build something like that.


Thanks Alf

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

[Scott Kitterman]

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//, 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

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

[Russ Allbery]

Thomas Goirand  writes:
> On 9/14/19 1:03 AM, Russ Allbery wrote:
>> Thomas Goirand  writes:

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

>> I use a computer with non-free firmware

> This has nothing to do with what I wrote, and you know it.

I don't know anything of the sort.  I do my Debian development on a host
running non-free software.  You said, right up above, that within the
Debian project we should forbid using non-free software.  Maybe that's not
what you *meant*, but that's what you *said*.

>> and push my packaging repositories
>> to (among other places) GitHub.

> As long as you push to Github *for yourself* (ie: not in order to share
> the repository with other people form the Debian community),

I use GitHub to share with anyone who uses GitHub.  I don't make them sign
some sort of statement saying they're not members of the Debian community
before they're allowed to use GitHub.  If other people in Debian want to
use GitHub rather than Salsa or my own Git server to clone my packages or
even to submit PRs, I don't care, and am happy to take contributions from
all of those channels.

If you weren't intending to challenge that, that's fine, but what you said
is that this should be forbidden, and that doesn't make sense to me.

> that's fine. But forcing it to others is not acceptable.

We have more agreement here, although there are a lot of details hidden in
what "forcing" really means.  But there's a huge space between "don't
force other people to use non-free software to contribute to Debian" and
"forbid using non-free software within the Debian project."

I feel like I can say with a very high degree of confidence that we're not
going to do the latter.  For instance, we're not going to stop using Intel
and AMD processors in the Debian project, even though they are full of
non-free software.  So whatever policy stance you're aiming for here needs
to be a lot more nuanced than how you're presenting it.

-- 
Russ Allbery (r...@debian.org)   

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

[Thomas Goirand]

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.

It is a real life experience that I had to touch horribly maintained
packages by unknown contributors, with Vcs-Git:
https://github.com//, 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.

Thomas Goirand (zigo)

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

[Alf Gaida]

Thomas Goirand  wrote:
> As long as you push to Github *for yourself* (ie: not in order to
> share the repository with other people form the Debian community),
> that's fine. But forcing it to others is not acceptable.
> 
> Thomas Goirand (zigo)
Thomas - what you want to achive?

Right now i'm affraid of you and others who share your opinion: There
will something happend as result:
* i will consider that my view on debian was just false
* i will move all my packaging to github or gitlab - the service don't
  matter, but it will make sure that i can have my workflow after the
  GR
* it will not hurt debian directly, because i will mirror the repo's to
  salsa
* there will be nice improvements in sense of my workflow coming with
  it: i will only accept github PRs - nothing else. I will only use
  github issues - because after such a descision i will suspspect the
  debian bts as not trustworthy

at all - i will have my packaging in a safe haven - and don't have to
care how nuts the outcome of a GR will be. Hey - if you really want it
that way, you layed out the first few meters of the new debian road.

Before i forget - if your plans happend, i will be verbose about - with
every contributor who will left debian alone after me. Promised.

Before there are false assumtions that i'm searching any consensus in
this unbelivable bullshit - no - i don't. I'll  only stepping aside
and see debian and debians ideas die. An cry silently. Thats all.

Alf



-- 
Alf Gaida
BDBF C688 EFAD BA89 5A9F  464B CD28 0A0B 4D72 827C

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

[Thomas Goirand]

On 9/14/19 1:03 AM, Russ Allbery wrote:
> Thomas Goirand  writes:
> 
>> 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.
> 
> I use a computer with non-free firmware

This has nothing to do with what I wrote, and you know it.

> and push my packaging repositories
> to (among other places) GitHub.

As long as you push to Github *for yourself* (ie: not in order to share
the repository with other people form the Debian community), that's
fine. But forcing it to others is not acceptable.

Thomas Goirand (zigo)

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

[Adam Borowski]

On Sat, Sep 14, 2019 at 01:02:03PM +0200, Bastian Blank wrote:
> On Sat, Sep 14, 2019 at 12:16:43PM +0200, Adam Borowski wrote:
> > And, despite a massive amount of efforts from you and others, packaged
> > gitlab is not fit for Salsa use.  It hasn't also ever been in a stable
> > release of Debian, despite being around since a year before Stretch's
> > freeze.
> 
> And even if there is a package, how do you plan to ask DSA to use it and
> run this service themselves?  Hint, as we told a hundred times before:
> Salsa runs on a DSA controlled machine, _without_ root.

Yet you use packaged exim, packaged postgres, packaged 1000-3000 other
pieces of software on a typical machine.  Those packages are good out of the
box.  They're stable and reliable.  Heck, you even use packaged git itself,
and it provides far far more functionality than a web interface to a small
subset of it.

And teams maintaining big important pieces manage to do their work despite
limited manpower.  It's just Gitlab and such that have a ridiculously bad
complexity-to-functionality ratio.

I thus stand by my point: I don't believe Gitlab will last, at least barring
some large-scale changes.  We've been there with Alioth.

> Let's compare it with other solutions:
> 
> ## GitLab unicorn application
> 
> * Ruby gems included directly: 199
> * Ruby gems included recursive: 333
> * node.js modules included directly: 113
> * node.js modules included recursive: 1760
> 
> Of the Ruby gems, 6 are from GitLab itself and are maintained separate.
> 
> With the listed software available everything is built from source.
> 
> ## gitea
> 
> * Go modules included: 122
> * node.js dependent projects vendored: 21
> 
> I assume the vendored stuff can be rebuild using this:
> 
> * node.js modules included directly: 8
> * node.js modules included recursive: 516
> 
> ## pagure
> 
> * Python modules required directly: 70
> * node.js dependent projects vendored: 16

## sr.ht

* unpackaged Python modules: 8
* node.js modules directly: 0
* node.js modules recursively: 0

It's in alpha stage, and uses a heathen snake-lover language I don't know,
but it's an example of a non-node.js implementation; engineering customs in
the node.js ecosystem are what I naively guess is the culprit here.


But, it's not a place for discussing alternate implementations (yet?), the
big question is: is Gitlab a sturdy enough foundation to _mandate_ or even
strongly recommend it for Debian workflows.  My response is a strong "no".


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

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

[Pirate Praveen]

On 2019, സെപ്റ്റംബർ 14 3:46:43 PM IST, Adam Borowski  
wrote:
>On Sat, Sep 14, 2019 at 09:37:00AM +0530, Pirate Praveen wrote:
>> I will also support such a GR.  I started packaging gitlab so we
>don't
>> have to compromise on ease of use compared to github.
>
>And, despite a massive amount of efforts from you and others, packaged
>gitlab is not fit for Salsa use.  It hasn't also ever been in a stable
>release of Debian, despite being around since a year before Stretch's
>freeze.

And the huge amount of work we put in to maintain gitlab is improving the base 
package quality of Debian, especially nodejs. We have packaged many core build 
tools like webpack, rollup, gulp, grunt etc which makes it easier to build many 
JavaScript libraries from source (we had to reverse engineer the build process 
before these were packaged, look at d3-format and jquery for example). rails is 
another example which is useful beyond gitlab. Also all the new people who 
joins gitlab team strengths the underlying ruby, js and golang teams.

I think I have to repeat these in regular intervals in -devel and probably a 
better way is to add it to gitlab wiki page and share link.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Sean Whitton]

Hello Pirate,

On Sun 15 Sep 2019 at 12:27AM +0530, Pirate Praveen wrote:

> That is not going to happen, instead we need to adapt ourselves to
> this fast paced development and fasttrack.debian.net is a step in that
> direction.

It's not just a matter of adapting workflows -- without real stable
releases, however good your workflows are, packaging GitLab and
administering GitLab installations demands more of people's time than it
would if there were real stable releases.

Real stable releases are freedom-enhancing when they free up people's
time to work on other stuff.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Pirate Praveen]

On 2019, സെപ്റ്റംബർ 14 3:46:43 PM IST, Adam Borowski  
wrote:
>On Sat, Sep 14, 2019 at 09:37:00AM +0530, Pirate Praveen wrote:
>> I will also support such a GR.  I started packaging gitlab so we
>don't
>> have to compromise on ease of use compared to github.
>
>And, despite a massive amount of efforts from you and others, packaged
>gitlab is not fit for Salsa use.  It hasn't also ever been in a stable
>release of Debian, despite being around since a year before Stretch's
>freeze.

I don't think looking at our current stable release cycle as holy standard for 
evaluating a software is the right approach. Backports was evolved to cater to 
a different need, it was not official when it was started. Similarly we now 
have http://fasttrack.debian.net being setup which includes gitlab.

>Looking at the number and complexity of packages needed solely for
>gitlab,
>I'd say that they'll collapse the moment you get busy with other tasks.

I understand this risk, that is the reason why I make sure more people join the 
team maintaining gitlab. I'm always mentoring new people and if you look at the 
tracker.debian.org for gitlab and dependencies, you will see more names 
uploading packages now. If you look at last 10 uploads of gitlab, 5 of it was 
not done by me. Initially gitlab inc was funding only me to work on gitlab 
packaging, now they fund me, Sruthi and Abhijith.

Earlier the gitlab package backports were only available from my 
people.debian.org repo which only I had access to. Now 3 people have access to 
fasttrack.debian.net already and the last upload was not done by me.

>This doesn't say anything good about Gitlab's design.
>
>(I'm quite obviously not bashing you, but your upstream.)
>
>I don't trust Gitlab's prolonged support.  Let's let it prove itself by
>being a part of a couple of stable releases -- and _then_ we can build
>upon
>its foundation.  That'd be a time frame already much accelerated
>compared to
>other core software projects.

That is not going to happen, instead we need to adapt ourselves to this fast 
paced development and fasttrack.debian.net is a step in that direction.

>Until then, I'll use git (which has greatly proven itself) but strongly
>refuse any ties to any particular platform.
>
>
>Meow!

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Jeremy Stanley]

On 2019-09-14 10:13:09 +0200 (+0200), Bastian Blank wrote:
> On Sat, Sep 14, 2019 at 10:29:32AM +0530, Balasankar "Balu" C wrote:
> > > 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?
> 
> https://lists.debian.org/msgid-search/20180819073423.xlnd4rqzc4elb...@shell.thinkmo.de

And for those not wanting to wade through the entire thread, I went
and talked to some service providers who offer a Gitlab-compatible
object store which is implemented entirely as free software
(OpenStack Swift), and got a genuine offer from one of those service
providers to donate access for the Debian project to use it as a
file back-end for Salsa:

https://lists.debian.org/debian-devel/2018/08/msg00300.html

Since this offer was simply ignored, I did not pursue the matter any
farther. I'd much rather Debian's community infrastructure not
depend on proprietary services (or open-core software products for
that matter), but I'm not the one running it. Instead I chose to
move on and spend my limited time furthering software freedom in
other venues where it can actually make a difference.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

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

[Bastian Blank]

On Sat, Sep 14, 2019 at 12:16:43PM +0200, Adam Borowski wrote:
> On Sat, Sep 14, 2019 at 09:37:00AM +0530, Pirate Praveen wrote:
> > I will also support such a GR.  I started packaging gitlab so we don't
> > have to compromise on ease of use compared to github.
> 
> And, despite a massive amount of efforts from you and others, packaged
> gitlab is not fit for Salsa use.  It hasn't also ever been in a stable
> release of Debian, despite being around since a year before Stretch's
> freeze.

And even if there is a package, how do you plan to ask DSA to use it and
run this service themselves?  Hint, as we told a hundred times before:
Salsa runs on a DSA controlled machine, _without_ root.

> Looking at the number and complexity of packages needed solely for gitlab,
> I'd say that they'll collapse the moment you get busy with other tasks.
> This doesn't say anything good about Gitlab's design.

Let's compare it with other solutions:

## GitLab unicorn application

* Ruby gems included directly: 199
* Ruby gems included recursive: 333
* node.js modules included directly: 113
* node.js modules included recursive: 1760

Of the Ruby gems, 6 are from GitLab itself and are maintained separate.

With the listed software available everything is built from source.

## gitea

* Go modules included: 122
* node.js dependent projects vendored: 21

I assume the vendored stuff can be rebuild using this:

* node.js modules included directly: 8
* node.js modules included recursive: 516

## pagure

* Python modules required directly: 70
* node.js dependent projects vendored: 16

Regards,
Bastian

-- 
Klingon phaser attack from front!
100% Damage to life support

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

[Adam Borowski]

On Sat, Sep 14, 2019 at 09:37:00AM +0530, Pirate Praveen wrote:
> I will also support such a GR.  I started packaging gitlab so we don't
> have to compromise on ease of use compared to github.

And, despite a massive amount of efforts from you and others, packaged
gitlab is not fit for Salsa use.  It hasn't also ever been in a stable
release of Debian, despite being around since a year before Stretch's
freeze.

Looking at the number and complexity of packages needed solely for gitlab,
I'd say that they'll collapse the moment you get busy with other tasks.
This doesn't say anything good about Gitlab's design.

(I'm quite obviously not bashing you, but your upstream.)

I don't trust Gitlab's prolonged support.  Let's let it prove itself by
being a part of a couple of stable releases -- and _then_ we can build upon
its foundation.  That'd be a time frame already much accelerated compared to
other core software projects.

Until then, I'll use git (which has greatly proven itself) but strongly
refuse any ties to any particular platform.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Your snowflakes have nothing on my socks drawer.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

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

[Bastian Blank]

On Sat, Sep 14, 2019 at 10:29:32AM +0530, Balasankar "Balu" C wrote:
> > 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?

https://lists.debian.org/msgid-search/20180819073423.xlnd4rqzc4elb...@shell.thinkmo.de

Regards,
Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0

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

[Balasankar "Balu" C]

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 
(replace  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 

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

[Pirate Praveen]

On 2019, സെപ്റ്റംബർ 14 4:21:16 AM IST, 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. 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.
>
>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. To some
>degree, it has already been partially opened.
>
>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.
>
>On 9/12/19 3:07 PM, Ian Jackson wrote:
>> We should resolve this with a GR.  Something like:
>
>I would second that GR. My opinion was that we would need a GR to
>enforce things, with this discussion, I'm even more convince we do need
>one. My problem was that I'm not as good writing nice English texts as
>you are. Good if you can do it.
>
>On 9/12/19 3:07 PM, Ian Jackson wrote:
>> Non-Debian services are
>> acceptable here so long as they are principally Free Software.
>
>s/principally/fully/
>
>Please, no compromise here. (or is it that I'm badly reading your
>English, and that "principally" means something else than in French?)
>
>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).
>
>So, exactly what do you think one can do, given the current situation?
>Or are you suggesting someone opens a solution that would compete
>what's
>been done on Salsa? This sounds counter-productive to me.
>
>On 9/12/19 4:51 PM, Ian Jackson wrote:
>> The latter is what I am trying to do.  I'm sorry that the opposite is
>> occuring.
>
>Ian, you're doing just right. I'm 100% with you on this. We shall not
>compromise, we did enough of that already, and in my opinion, we are
>already leaning too much on the wrong direction with Salsa.
>
>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!

I will also support such a GR. I started packaging gitlab so we don't have to 
compromise on ease of use compared to github.

>On 9/13/19 9:39 AM, Enrico Zini wrote:
>> This cannot be the discussion culture of a group where I can be
>> comfortable working with others.
>
>I'm feel sorry to read these lines, though, I don't see how we can
>compromise on how much free Debian should be. I'm very surprised read
>you're not comfortable working in a group where some of us are pointing
>this out. Now, this makes *me* uncomfortable. That's not what I thought
>Debian was about then. I thought we all signed up on "Debian will
>remain
>100% free"... How come we don't have a strong consensus on this then?
>Have some of us just given-up on software freedom?

>Thomas Goirand (zigo)

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Alf Gaida]

On Sat, 14 Sep 2019 00:51:16 +0200
Thomas Goirand  wrote:

> Sorry, WHAAAT ? That's shocking to read this from the DPL.
> Are you sure you didn't do a mistake in this sentence?
Sorry, Sam is right, he just read and understand the DSC $1 right. If
one work on Debian with non-free tools that will not make the result
non-free. 

> There's absolutely no problem within the Debian project to forbid
> using non-free software. 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.
Nope, you signed up that debian will remain 100% free - not for the
tools people work with.  And if debian would forbid the usage of
non-free software to work on some code - i would be the first to leave
the project. I don't use much non-free beside my graphics drivers and
some firmware - but nobody is entitled to forbid me to use bcompare or
github or maybe a commercial editor - nobody has the right to dictate my
tools. Regarding the software: Software has to be free and
should not depend on non-free tools - but to forbid non-free tools if
there are equiv. free interchangeble tools is far over the top.

--- snap  ---

> On 9/13/19 9:39 AM, Enrico Zini wrote:
> > This cannot be the discussion culture of a group where I can be
> > comfortable working with others.  
Fully agree.

> I'm feel sorry to read these lines, though, I don't see how we can
> compromise on how much free Debian should be. I'm very surprised read
> you're not comfortable working in a group where some of us are
> pointing this out. Now, this makes *me* uncomfortable. That's not
> what I thought Debian was about then. I thought we all signed up on
> "Debian will remain 100% free"... How come we don't have a strong
> consensus on this then? Have some of us just given-up on software
> freedom?
And again - i'm not comfortable with this reading of §1 - like it or
not - if your opinion and reading is the consensus and supported by the
majority in debian it will be time for me to leave as fast as i can and
don't look back. Would make me a bit sorry for the then wasted years -
but hey, life goes on. 

And i subscribed the same things as you do and had no problem to do so.
I'm all for free software, i spend the very most of my spare time to it
- not only in debian. But if the official reading will be your
  interpretation: Sorry, i'm out, can't and will not follow - in that
  special case there will be some projects that fit my needs better.

Cheers Alf

PS: Please read this in the context of my former posts - this
discussion would not happend if all the packages are hosted used debian
infrastructure - and i'm dead set against using non-free infra in
debian. One exception: I don't consider firmware and processor patches
as Software in the sense of DFSG - so the servers we are running should
be allowed to use the newest firmware and processor patches they need)

Cheers Alf

> Thomas Goirand (zigo)
> 



-- 
Alf Gaida
BDBF C688 EFAD BA89 5A9F  464B CD28 0A0B 4D72 827C

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

[Scott Kitterman]

On September 13, 2019 10:51:16 PM UTC, 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. 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.
>
>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. To some
>degree, it has already been partially opened.
>
>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.
>
>On 9/12/19 3:07 PM, Ian Jackson wrote:
>> We should resolve this with a GR.  Something like:
>
>I would second that GR. My opinion was that we would need a GR to
>enforce things, with this discussion, I'm even more convince we do need
>one. My problem was that I'm not as good writing nice English texts as
>you are. Good if you can do it.
>
>On 9/12/19 3:07 PM, Ian Jackson wrote:
>> Non-Debian services are
>> acceptable here so long as they are principally Free Software.
>
>s/principally/fully/
>
>Please, no compromise here. (or is it that I'm badly reading your
>English, and that "principally" means something else than in French?)
>
>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).
>
>So, exactly what do you think one can do, given the current situation?
>Or are you suggesting someone opens a solution that would compete
>what's
>been done on Salsa? This sounds counter-productive to me.
>
>On 9/12/19 4:51 PM, Ian Jackson wrote:
>> The latter is what I am trying to do.  I'm sorry that the opposite is
>> occuring.
>
>Ian, you're doing just right. I'm 100% with you on this. We shall not
>compromise, we did enough of that already, and in my opinion, we are
>already leaning too much on the wrong direction with Salsa.
>
>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!
>
>On 9/13/19 9:39 AM, Enrico Zini wrote:
>> This cannot be the discussion culture of a group where I can be
>> comfortable working with others.
>
>I'm feel sorry to read these lines, though, I don't see how we can
>compromise on how much free Debian should be. I'm very surprised read
>you're not comfortable working in a group where some of us are pointing
>this out. Now, this makes *me* uncomfortable. That's not what I thought
>Debian was about then. I thought we all signed up on "Debian will
>remain
>100% free"... How come we don't have a strong consensus on this then?
>Have some of us just given-up on software freedom?

The logical conclusion of this line of argument is that I'm only allowed to do 
my packaging work on a computer that doesn't require non-free firmware blobs, 
because doing otherwise is using non-free tools to make Debian.

Are you willing to create a fully free software based CDN and commit to 
maintaining it for the foreseeable future so that we can stop using commercial 
CDN services without harming our users?

Heck, we should probably shut down any mirrors using hardware with non-free 
firmware too.

Scott K

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

[Russ Allbery]

Thomas Goirand  writes:

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

I use a computer with non-free firmware and push my packaging repositories
to (among other places) GitHub.  Should I therefore not be allowed to do
Debian work?

It's that sort of tool that Sam is talking about.

This is not new.  This is the reason the FSF has at times been mildly
irritated with us: we are willing to make compromises to get Debian to run
on the computers that people actually have, instead of refusing to
reference anything other than software that can only run on a tiny handful
of machines, as much as we would love for more purely free-software
devices to exist.  I feel like interacting with GitHub *among others* (my
primary packaging repositories are on my own personal infrastructure) is
in the same vein, and in the same spirit as the FSF being willing to
support porting of their software to Solaris back in the day.  If free
software is a closed world only usable by people who are already devoted
to free software, we will fail as a political movement.

Even with that disagreement and their additional level of purity here, the
FSF still has not achieved the goal if not using any non-free tools or
non-free software, given that they're still using Intel and AMD
processors, which *absolutely* contain non-free software.

-- 
Russ Allbery (r...@debian.org)   

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

[Thomas Goirand]

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

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. To some
degree, it has already been partially opened.

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.

On 9/12/19 3:07 PM, Ian Jackson wrote:
> We should resolve this with a GR.  Something like:

I would second that GR. My opinion was that we would need a GR to
enforce things, with this discussion, I'm even more convince we do need
one. My problem was that I'm not as good writing nice English texts as
you are. Good if you can do it.

On 9/12/19 3:07 PM, Ian Jackson wrote:
> Non-Debian services are
> acceptable here so long as they are principally Free Software.

s/principally/fully/

Please, no compromise here. (or is it that I'm badly reading your
English, and that "principally" means something else than in French?)

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).

So, exactly what do you think one can do, given the current situation?
Or are you suggesting someone opens a solution that would compete what's
been done on Salsa? This sounds counter-productive to me.

On 9/12/19 4:51 PM, Ian Jackson wrote:
> The latter is what I am trying to do.  I'm sorry that the opposite is
> occuring.

Ian, you're doing just right. I'm 100% with you on this. We shall not
compromise, we did enough of that already, and in my opinion, we are
already leaning too much on the wrong direction with Salsa.

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!

On 9/13/19 9:39 AM, Enrico Zini wrote:
> This cannot be the discussion culture of a group where I can be
> comfortable working with others.

I'm feel sorry to read these lines, though, I don't see how we can
compromise on how much free Debian should be. I'm very surprised read
you're not comfortable working in a group where some of us are pointing
this out. Now, this makes *me* uncomfortable. That's not what I thought
Debian was about then. I thought we all signed up on "Debian will remain
100% free"... How come we don't have a strong consensus on this then?
Have some of us just given-up on software freedom?

Thomas Goirand (zigo)

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

[Alf Gaida]

On 13.09.19 17:55, Russ Allbery wrote:
> There seems to be an obvious ordering issue here, namely that it's very
> weird to insist on the first (which has been the topic of this thread)
> before we insist on the second.

I wouldn't see it as an ordering issue - my POV is that each of these
issues is independend. Maybe it is just wishful thinking - but it would
not really matter, in which direction these issues would be addressed.


If i should setup a priority list it would be:

1) all packaging sources must be hosted in debian infrastructure (no
matter in which way)

2) all packages should use a SCM (no matter what)

3) finally (maybe) consider git as the only supported SCM


Each of these three points is controversial - i know. But it would be a
nice goal.


Cheers Alf

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

[Russ Allbery]

Alf Gaida  writes:

> Is it really so hard to understand? Github, Gitlab and other service are
> just tools. I don't care if they are free or non-free. No account, no
> participation. And if you had read the whole post - imho the best
> outcome woul be: No hosting of Debian packaging outside  Debian
> infrastructure. Second thing i would prefer: Packaging has to use a VCS
> supported in the debian project. If it boils down to:  We  support only
> git in our infrastructure - fine.

There seems to be an obvious ordering issue here, namely that it's very
weird to insist on the first (which has been the topic of this thread)
before we insist on the second.

Right now, we don't require people use *any* special tool to maintain
their packages.  They can just apt-get source, make changes with a text
editor, and then build a source package and upload.  It's therefore very
weird, and kind of off-putting, to have people who start using Git be
suddenly subject to *more* constraints about how they do their work than
people who aren't using a VCS at all.

If we get to the point where everyone has to use Git, then it's logical
(if possibly still not what we want to do) to take a more opinionated
stance on where those Git repositories are replicated to.  (And of course
the nice thing about Git is that you can easily put repositories in
multiple places.)  But for as long as we're not willing to require people
use a VCS (which I think would be rather controversial), it doesn't make
sense to me to have strong opinions about where the Git repository is if
they use one.

-- 
Russ Allbery (r...@debian.org)   

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

[Bastian Blank]

On Fri, Sep 13, 2019 at 02:51:47PM +0200, Alf Gaida wrote:
> On 9/13/19 10:18 AM, Bastian Blank wrote:
> > On Thu, Sep 12, 2019 at 06:34:42PM +0200, Alf Gaida wrote:
> >> Regarding the workflow and participation - it might be a problem that
> >> one need an account for github or other non-free services - it's easy:
> > You also need accounts for _free_ services, so what do you want to say?
> Is it really so hard to understand? Github, Gitlab and other service are
> just tools. I don't care if they are free or non-free. No account, no
> participation.

You imply that by using _free_ services, you need _no_ accounts.  This
statement is false.

Bastian

-- 
There is a multi-legged creature crawling on your shoulder.
-- Spock, "A Taste of Armageddon", stardate 3193.9

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

[Alf Gaida]

On 13.09.19 15:10, Simon Richter wrote:
> Hi,
>
> On Fri, Sep 13, 2019 at 02:51:47PM +0200, Alf Gaida wrote:
>
>> Is it really so hard to understand? Github, Gitlab and other service are
>> just tools. I don't care if they are free or non-free.
> For Debian, free software is kind of important.
>
>Simon

Simon - if you cite me, you should cite the relevant part. Really, the
text wasn't that long:

> Is it really so hard to understand? Github, Gitlab and other service are
> just tools. I don't care if they are free or non-free. No account, no
> participation. And if you had read the whole post - imho the best
> outcome woul be: No hosting of Debian packaging outside  Debian
> infrastructure. Second thing i would prefer: Packaging has to use a VCS
> supported in the debian project. If it boils down to:  We  support only
> git in our infrastructure - fine.

No hosting outside of debian means: One has to use Debian infrastructure
- and we only use services we consider free, don't we? So it's is not
relevant if other services are free or non-free. It wouldn't matter.


Cheers Alf

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

[Simon Richter]

Hi,

On Fri, Sep 13, 2019 at 02:51:47PM +0200, Alf Gaida wrote:

> Is it really so hard to understand? Github, Gitlab and other service are
> just tools. I don't care if they are free or non-free.

For Debian, free software is kind of important.

   Simon

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

[Alf Gaida]

On 9/13/19 10:18 AM, Bastian Blank wrote:
> On Thu, Sep 12, 2019 at 06:34:42PM +0200, Alf Gaida wrote:
>> Regarding the workflow and participation - it might be a problem that
>> one need an account for github or other non-free services - it's easy:
> You also need accounts for _free_ services, so what do you want to say?

Is it really so hard to understand? Github, Gitlab and other service are
just tools. I don't care if they are free or non-free. No account, no
participation. And if you had read the whole post - imho the best
outcome woul be: No hosting of Debian packaging outside  Debian
infrastructure. Second thing i would prefer: Packaging has to use a VCS
supported in the debian project. If it boils down to:  We  support only
git in our infrastructure - fine.

Cheers Alf

>
> Bastian
>

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

[Bastian Blank]

On Thu, Sep 12, 2019 at 06:34:42PM +0200, Alf Gaida wrote:
> Regarding the workflow and participation - it might be a problem that
> one need an account for github or other non-free services - it's easy:

You also need accounts for _free_ services, so what do you want to say?

Bastian

-- 
Lots of people drink from the wrong bottle sometimes.
-- Edith Keeler, "The City on the Edge of Forever",
   stardate unknown

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

[Enrico Zini]

On Thu, Sep 12, 2019 at 03:51:57PM +0100, Ian Jackson wrote:

> Well, thanks for the rebuke.  I hope I have clarified my thinking and
> please do the same again in future.  (Or, indeed, right now, if you
> think this message is still frightening...)

I wish you could learn to *listen* first, then maybe argue. You still
proceeded to argue at me without really asking any question about where
I was coming from.

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.

This cannot be the discussion culture of a group where I can be
comfortable working with others.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

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

[Ian Jackson]

Sam Hartman writes ("Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github"):
> Ian Jackson  writes:
> 
> > Sam Hartman writes ("Re: Git Packaging Round 2: SHOULD Not or
> > MUSt NOT Github"):
> >> Unfortunately, I believe you are in the [wrong] when judging
> 
> Ian placed the word "wrong" in my mouth replacing the word "rough" from
> my original mail.  I disagree with that characterization of what I said
> in the strongest possible terms.

I'm sorry, I genuinely thought you had made a typo.  The sentence

  Unfortunately, I believe you are in the rough when judging rough
  consensus on this issue.

didn't make sense to me.  I should have stared at it for longer and
then maybe I would have seen what you meant.

>When I say that Ian is in the rough, I mean that I think there is
> not a perfect consensus on the issue, and that Ian holds an view
> that is inconsistent with what consensus exists.

Thanks for the explanation.

Ian.

-- 
Ian JacksonThese 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.

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

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian> Sam Hartman writes ("Re: Git Packaging Round 2: SHOULD Not or
Ian> MUSt NOT Github"):
>> Unfortunately, I believe you are in the [wrong] when judging

Ian placed the word "wrong" in my mouth replacing the word "rough" from
my original mail.  I disagree with that characterization of what I said
in the strongest possible terms.  Judging consensus is not about finding
right or wrong; it is not about a moral judgment at all.  Judging
consensus is about finding agreement (or its lack).  When I say that Ian
is in the rough, I mean that I think there is not a perfect consensus on
the issue, and that Ian holds an view that is inconsistent with what
consensus exists.  I'm also implying by that statement that the
discussion is not ongoing; that we've reached a good enough
approximation of consensus to move on even though some people wish we
had reached a different conclusion.

>> More over your claim that this is not our current practice runs
>> counter to facts. Of the 26,480 packages in my unstable sources
>> with a vcs-git, 1836 are on github.  7% seems much more
>> consistent to me with "NOT Recommended" than "forbidden."

Ian> Blimey.  I didn't realise that.

Ian> I think this does not demonstrate that I am wrong about
Ian> project's overall opinion about this.  I am confident that a GR
Ian> to forbid this would succeed.

Ian> It just demonstrates that we have few working enforcement
Ian> mechanisms against contributors who violate our norms.

>> Even if there is not rough consensus to forbid non-free services,
>> I'd welcome help documenting the concerns that can come up.

Ian> I think this is a question of Debian's core values.

Ian> Given the current situation, with 7% of packages in violation
Ian> of what I see as a key norm, it seems that this cannot be
Ian> resolved via a consensus process.

Ian> We should resolve this with a GR.  Something like:

This sounds like a discussion that would be better on debian-project.
I'll try and move it there, quoting your draft text.

--Sam

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

[Alf Gaida]

On Thu, 12 Sep 2019 08:47:49 -0400
Sam Hartman  wrote:
> That said, I'm really confused that your message didn't get any
> response before now.  Considering how sharp some of the responses
> were on -project, I don't know how to take this.  Were people not
> responding because the -project discussion was so recent, they didn't
> see a need to rehash it?  Were people not responding because -devel
> has a very different audience and everyone here agrees with you?
That's really easy: Most people aviod harsh or sharp answers, i'm not.
And to be honest, i don't really understand all the discussions about
git. It's just a tool - and most of the time misused in debian. Not
that i'm the biggest git expert on earth - i'm only a happy user for
ten years now. And the ten years include bitbucket, github, gitlab,
gitblit, gitea, gitolite, gerrit and so on - so it is totally
irrelevant to some extend where things are hosted, it remains git in
the very end.

Regarding the workflow and participation - it might be a problem that
one need an account for github or other non-free services - it's easy:
No account, no participation, bad luck. In one thing Ian is right:
Debian packages should not be hosted on non-free services. I would go a
step further: No Debian package must be hosted outside of debian.
Period. Problem solved. That would prevent problems like the ones with
debian live hosted by Progress Linux, LXDE packaging hosted on
https://git.lxde.org (broken for some month now) and so on. Would really
make sense, but is a different story.

Another though: If we start not to allow packaging on non free services
and using non-free tools - what would be next: Considering projects
that use non-free services like github or bitbucket as non-free - in
this case please drop the whole LXQt from debian, we will continue to
use github.com in near future and are not planning a change right now.

Cheers Alf

-- 
Alf Gaida
BDBF C688 EFAD BA89 5A9F  464B CD28 0A0B 4D72 827C

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

[Ian Jackson]

Enrico Zini writes ("Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github"):
> On Thu, Sep 12, 2019 at 02:07:52PM +0100, Ian Jackson wrote:
> > I think this does not demonstrate that I am wrong about project's
> > overall opinion about this.  I am confident that a GR to forbid this
> > would succeed.
> 
> For what is worth, I would vote against such a GR.
> I'm extremely uncomfortable reading what you wrote.

I'm sorry to hear that.

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

The latter is what I am trying to do.  I'm sorry that the opposite is
occuring.

> I wish this work would be grounded instead on an acknowledgement and
> acceptance of the, imperfect, diverse, yet still valid status quo.

For me, my opposition to github has nothing to do with my desire to
improve Debian's workflows.

I am indeed trying to improve Debian's workflows by providing better
options.  Options that I hope people will voluntarily adopt, and that
will become more officially recommended - but *not* mandatory.

On the other hand, my opposition to github is like my opposition to
the inclusion of software in main which automatically and without
adequate user permission downloads and runs proprietary binary DRM
code.  Or like the arguments we've had over the lack of proper source
code for some javascript and machine language programs.  Software has
been blocked from Debian, and valuable contributors discouraged, as a
result.

Should we also tolerate these freedom problems as an "imperfect,
diverse, yet still valid status quo" ?  Is it unjustifiably "coercive"
to block non-free software from Debian main ?

I guess one lesson I should perhaps learn is that it is difficult for
me in particular to push on these kind of software freedom issues when
they are entangled with workflow issues, because of inevitable
confusion/conflation/whatever.

So maybe I should leave the "Free Software Needs Free Tools"[1]
advocacy to others.  I do still think it's important.
  [1] https://mako.cc/writing/hill-free_tools.html

> Thankfully I still consider it to be so, with the exception of the
> occasional frightening cohercive twist in some of your mails.

Well, thanks for the rebuke.  I hope I have clarified my thinking and
please do the same again in future.  (Or, indeed, right now, if you
think this message is still frightening...)

Regards,
Ian.

-- 
Ian JacksonThese 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.

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

[Enrico Zini]

On Thu, Sep 12, 2019 at 02:07:52PM +0100, Ian Jackson wrote:

> I think this does not demonstrate that I am wrong about project's
> overall opinion about this.  I am confident that a GR to forbid this
> would succeed.

For what is worth, I would vote against such a GR.

I'm extremely uncomfortable reading what you wrote.

I consider you one of the leading actors of the current discussion on
improving/cleaning/redesigning default workflows in Debian, and I
respect you as such.

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.

I wish this work would be grounded instead on an acknowledgement and
acceptance of the, imperfect, diverse, yet still valid status quo.

Thankfully I still consider it to be so, with the exception of the
occasional frightening cohercive twist in some of your mails.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

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

[Ian Jackson]

Sam Hartman writes ("Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github"):
> Unfortunately, I believe you are in the [wrong] when judging rough
> consensus on this issue.
> 
> This was discussed fairly recently on debian-project; my take is that
> Thomas Goirand represented a position roughly the same as your own.
> My reading of that discussion is that:

Thomas was making a lot of much stronger assertions about what should
be done.

> More over your claim that this is not our current practice runs counter
> to facts. Of the 26,480 packages in my unstable sources with a vcs-git,
> 1836 are on github.  7% seems much more consistent to me with "NOT
> Recommended" than "forbidden."

Blimey.  I didn't realise that.

I think this does not demonstrate that I am wrong about project's
overall opinion about this.  I am confident that a GR to forbid this
would succeed.

It just demonstrates that we have few working enforcement mechanisms
against contributors who violate our norms.

> Even if there is not rough consensus to forbid non-free services, I'd
> welcome help documenting the concerns that can come up.

I think this is a question of Debian's core values.

Given the current situation, with 7% of packages in violation of what
I see as a key norm, it seems that this cannot be resolved via a
consensus process.

We should resolve this with a GR.  Something like:

  Subject: Free Software Needs Free Tools

  No Debian contributor should be expected or encouraged, when working
  to improve Debian, to use non-free tools.  This includes proprietary
  web services.  We will ensure this, insofar as it is within Debian's
  collective control.

  For example, Vcs-Git fields in source packages must not refer to
  proprietary git code management systems.  Non-Debian services are
  acceptable here so long as they are principally Free Software.

  We encourage all our upstreams to use Free/Libre tools.

  We recognise that metadata in Debian which describes the behaviour
  of those outside our community, for example fields which refer to
  upstream source management systems, may (in order to be accurate)
  still need to refer to proprietary systems.

Ian.

-- 
Ian JacksonThese 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.

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

[Sam Hartman]

> "Ian" == Ian Jackson  writes:


Ian> No-one should be asked to interact with a non-free service, as
Ian> part of contributing to Debian.

Ian> Note I say "no-one should be asked".  It is not enough, for me,
Ian> for there to be a "plan (b)" route.  Ie, it is not OK for a
Ian> maintainer to advertise a github repo as preferred, or to ask
Ian> for PRs on github, even if an alternative or mirror, or Salsa,
Ian> or the BTS are also advertised.

Ian> This is for two reasons: firstly, this is a matter of
Ian> principle.  Our mission is free software.  Free software needs
Ian> free tools.  We should not be advertising or encouraging the
Ian> use of non-free tools.

I agree that many people in the project want us to work hard to avoid
encouraging non-free tools.
I agree that's a significant consideration.

Ian> Secondly, there is a practical problem if a maintainer (even a
Ian> solo maintainer) chooses to regard a nonfree service as
Ian> primary.  If another person comes along and wants to help out
Ian> with that package, they will either have to also tolerate using
Ian> the nonfree service, or they will have to try to persuade the
Ian> maintainer to abandon their existing hosting or tools (and
Ian> maybe the maintainer's existing workflow, if the nonfree tools
Ian> are significantly different).  For me that is wholly
Ian> unacceptable.

I agree that this can be a consequence of using non-free tools.
I believe those involved in the discussions around this issue have
considered this consequence.

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

Ian> This is no good as an answer.

Ian> In practice imprecations to a team (or a maintainer) to "find a
Ian> solution so that a Debian contributor can contribute
Ian> effectively" will be useless because:

Ian> (i) Even having to ask this question already makes the new
Ian> contributor seem awkward, puts them at a social disadvantage,
Ian> and perhaps annoys people.

Ian> (ii) We lack workable enforcement mechanisms for this kind of
Ian> imprecation.  (Because we lack *any* workable enforcement
Ian> mechanisms to deal with obstructive maintainer behaviours.)

Ian> (iii) Even if everyone has good will, and or even if we had
Ian> excellent and proportionate and swift enforcement mechanism,
Ian> there will inevitably be a delay and hassle and friction.

I agree that these are problems you can run into.

Ian> ...
>> Using non-free services for Debian packaging is not recommended
>> but is permitted.

Ian> I strongly disagree with this, or at least, with what seems to
Ian> me to be the obvious implication.  It is also contrary to our
Ian> current practice.

Unfortunately, I believe you are in the rough when judging rough
consensus on this issue.

This was discussed fairly recently on debian-project; my take is that
Thomas Goirand represented a position roughly the same as your own.
My reading of that discussion is that:

1) there are significant problems we'd run into if we forbid  non-free tools in
Debian work

2) There was not sufficient support in that discussion to do so anyway

3) There are significant problems that come up when non-free tools are
used.  The problems enumerated were similar to the problems you describe
above.

More over your claim that this is not our current practice runs counter
to facts. Of the 26,480 packages in my unstable sources with a vcs-git,
1836 are on github.  7% seems much more consistent to me with "NOT
Recommended" than "forbidden."

I think you would take exception if I said that dgit (940 packages in my
unstable sources--about half the github count) ran counter to current
practice. Yes, that is comparing apples to oranges on a number of
levels.  My point is that there is a significant fraction of our
developers who do use github and that it seems to be a current practice.

That said, I'm really confused that your message didn't get any response
before now.  Considering how sharp some of the responses were on
-project, I don't know how to take this.  Were people not responding
because the -project discussion was so recent, they didn't see a need to
rehash it?  Were people not responding because -devel has a very
different audience and everyone here agrees with you?

In terms of next steps.  I'd recommend that you read the -project
discussion.  Your arguments here are not responsive to several of the
counters brought up in that discussion.  Obviously you may disagree with
the trade offs expressed, but it would be valuable for you to consider
the points made in that discussion.  Even so, based on that discussion
and the active use of github, my take is that we do not have a rough
consensus to forbid non-free