Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[gregor herrmann]

On Wed, 24 Jul 2019 12:23:42 +, Scott Kitterman wrote:

> We are
> perfectly capable of phasing out obsolete workflows without a
> hammer like a GR (remember dpatch).

Unrelated to the general topic but since you mention it: Yes I
remember dpatch -- it's not phased out, I just encountered it a few
days ago.


Cheers,
gregor 

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Re: anti-tarball clause and GPL

[Yao Wei (魏銘廷)]

What if, one of the upstream authors consider it violating GPL _without_ the 
clause?  I mean, it could happen. 

Yao Wei

Re: Upstream metadata to help our users contribute back to projects we redistribute.

[Paul Wise]

On Thu, Jul 25, 2019 at 4:28 PM Charles Plessy wrote:

> This is why some packges are shipping metadata indicating where to find
> the upstream sources, send upstream bugs, or even where to dontate
> money, in order to help our users contribute back to the developement
> of the software that Debian is made of.
>
> For many of you, I am sure that it is only a reminder.  But in any case
> please have a look at https://wiki.debian.org/debian/upstream and
> https://wiki.debian.org/AppStream for details.

You might want to copy this reminder to Misc Dev News:

https://wiki.debian.org/DeveloperNews

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Upstream metadata to help our users contribute back to projects we redistribute.

[Jelmer Vernooij]

On 25 July 2019 15:17:13 GMT+01:00, Felipe Sateler  wrote:
>On Thu, 25 Jul 2019 17:27:51 +0900, Charles Plessy wrote:
>
>> Hello everybody,
>
>Hello Charles,
>
>> 
>> (posted on -project because of the context, but answers probably
>belong
>> to -devel, where I am not subscribed...)
>> 
>> there is an intersting discussion going on about Git and the
>preferred
>> form for modification of the programs we redistribute.
>> 
>> Indeed, as of today would be hard to say « just run “apt-get source
>> ” and voilà, you can hack and contribute back upstream
>».
>> 
>> There has been now and in the past (for instance when discussing the
>> proposed format “3.0 (Git)” for dpkg) some important points raised
>> explaining the challenge of redistributing the upstream VCS instead
>of a
>> flat file archive.
>> 
>> This is why some packges are shipping metadata indicating where to
>find
>> the upstream sources, send upstream bugs, or even where to dontate
>> money, in order to help our users contribute back to the developement
>of
>> the software that Debian is made of.
>
>Are there tools that are actively using this information?
>Unfortunately, 
>the links you quote below do not provide much information about where 
>this information is used (other than bibref table in UDD).
>
>On the other side of the coin, are there any tools that help generate 
>this metadata? For example, github-hosted projects can have their Bug-
>Database, Bug-Submit, Changelog, Repository, Repository-Browse 
>automatically derived.

lintian-brush (https://packages.debian.org/intuan-brush) can update 
debian/upstream/metadata from various kinds of upstream-bundled files like 
dist.ini, META.json, doap (used by GNOME) or setup.py.

Jelmer

Re: anti-tarball clause and GPL

[Norbert Preining]

On Thu, 25 Jul 2019, Russ Allbery wrote:
> is a *huge* amount of disruption and energy drain because we have to
> relitigate endless mostly-settled discussions from the past thirty years
> around what source code means.  The payoff needs to be correspondingly
> large to be worth the effort, and I'm just not seeing it.

Strongly supported, thanks for the very clear statement!

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: anti-tarball clause and GPL

[Norbert Preining]

On Wed, 24 Jul 2019, Yao Wei wrote:
> I believe that "flat" tarball in Adam's question means tarball stripping
> out VCS information, not tarball as a format.
> 
> Also, the clause doesn't disallow the distribution using tarball, but
> only define what "source code == preferred form for making modification"
> is.  So, "flat tarball" becomes object code license-wise.

Just one hint, if this comes in I will upload texlive with about a
70Gb tarball as source ... we have 15 years of history of "flat tarball
of 4Gb".

I don't think that *this* is the preferred form of changes.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: anti-tarball clause and GPL

[Adam Borowski]

On Tue, Jul 23, 2019 at 09:51:23PM -0300, Yao Wei wrote:
> On Wed, Jul 24, 2019 at 12:49:24AM +0200, Adam Borowski wrote:
> > ##
> > I do not consider a flat tarball to be a preferred form for modification. 
> > Thus, like any non-source form, it must be accompanied by a way to obtain
> > the actual form for modification.  There are many such ways -- unless you
> > distribute the software in highly unusual circumstances, a link to a
> > network server suffices; see the text of the GPL for further details.
> > ##
> 
> I believe transporting whole VCS directory in a tarball is a viable
> workaround

Ie, the 3.0 (git) format.

> though I would argue that expensive data transport (like 4G,
> satellite network, etc.) is not highly unusual.

Using real git (rather than a hack to emulate the old scheme) you can do a
shallow clone.

Tunnelling git repos inside tarballs is useful only in rare (yet important)
cases like a desert island, an oppressive country, an air-gapped facility,
an interstellar spaceship, etc.  And once tunnelled, git will works
awesomely within that disconnected from us network.  Including merging back
once connected again.  That's not something a flat tarball can do.

> Also, if upstream interpret the clause as "the actual place for making
> modification", it could violate dissident test.

I'm talking about format, not place.  Git is explicitly a _distributed_ VCS,
meant to solve this very problem.

And mandating git specifically would be non-free, as it'd forbid migrating
to a future better scheme, or an alternative (Hg, Pijul).  Thus, I propose
opt-in banning only a particular obsolete way to convey processed sources.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄

Re: anti-tarball clause and GPL

[Michael Stone]

On Thu, Jul 25, 2019 at 09:56:49AM -0700, Russ Allbery wrote:

The payoff needs to be correspondingly
large to be worth the effort, and I'm just not seeing it.


+1

Re: Upstream metadata to help our users contribute back to projects we redistribute.

[Felipe Sateler]

On Thu, 25 Jul 2019 16:26:02 +0200, Xavier wrote:

> Hi,
> 
> pkg-js-tools embeds a tool that generates debian/upstream/metadata for
> Github repositories (github-missing-upstream).

Thanks, this is useful. It's named github-debian-upstream though ;)

> 
> dpt from pkg-perl-tools uses this file to link locally upstream repo in
> "git remote"

This sounds cool too. Sounds more useful than for just perl packages.


-- 
Saludos,
Felipe Sateler

Re: anti-tarball clause and GPL

[Russ Allbery]

Adam Borowski  writes:

> At this moment, not yet.  Obviously, old projects didn't even _have_ a
> VCS, and I'm not proposing imposing a VCS workflow on the upstream.  I'd
> like to consider, at some point in the future, hidden private VCSes
> where the upstream occassionally releases a tarball of to be non-free,
> just like the same PNG image can be free if there's no XCF file but is
> not if the upstream holds a private XCF version they routinely modify --
> a "preferred form for modification" is not required to be good, merely
> no worse than what upstream themselves use.

I don't understand why you chose the VCS specifically and alone to elevate
to the level of required source.  If I had to pick what additional
information I'd want over and above the current source code, I'd be way
more interested in the bug tracking system than the VCS.  I use that an
order of magnitude more often than I use Git history when developing
software.

There are a few other really obvious reductio ad absurdum arguments here,
too.  For example, most of the critical documentation for the Linux kernel
that's practically required in order to understand it well enough to
meaningfully maintain it is in LWN or the linux-kernel mailing list
archives.  Guess we need to start including those in the source package
now too

The line between source and supporting useful stuff that's not source is
inherently arbitrary.  For better or worse, we have thirty years of
history behind drawing the line in one specific place.  That doesn't mean
there are no good reasons to change that line; it does mean that any other
place we draw the line is still going to be arbitrary.  Redrawing the line
is a *huge* amount of disruption and energy drain because we have to
relitigate endless mostly-settled discussions from the past thirty years
around what source code means.  The payoff needs to be correspondingly
large to be worth the effort, and I'm just not seeing it.

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

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Tollef Fog Heen]

]] Thomas Goirand

> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> packaging.

Like Steve said, there are cases where git is not the right
tool. Recommending, fine.  Mandating?  No, I think that would be a bad
idea.

> 2- Mandating using the "gbp patches unapplied" layout for Git, as this
> seems to be the most popular layout, and that we need some kind of
> consistency.

It seems to be self-evident to you that we need consistency.  It's not
at all clear to me that having a single layout to rule them all is the
right path forward.  Why do you think we should just have a single
layout?

Beyond that, I think we should move away from patches-unapplied rather
than towards it.  If you look at how normal software development is done
today, it's done with a git repo and not shuffling patches-as-files back
and forth.

I also think that having a single way of solving a problem will keep us
back from further evolution.  Freedom to experiment is useful, and by
having this as a GR, the only way forward from this would be to have
another GR to change to something else.  Binding ourselves that way
doesn't seem wise.

As for what you wrote downthread about possible to use 1.0 native
packages: yes,

> 3- Mandating using Salsa as a Git repository.

Again I think this proposal fails to account for corner cases, as an
example on top of what other have talked about: this could end up
affecting what can go into non-free.  This would also increase coupling,
something we already have a problem with, and which is considered a bad
idea in software development.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: anti-tarball clause and GPL

[Adam Borowski]

On Wed, Jul 24, 2019 at 05:18:28AM +, Scott Kitterman wrote:
> On July 24, 2019 12:34:13 AM UTC, Adam Borowski  wrote:
> >By this logic, a pile of .c files with comments removed or preprocessed
> >with cpp would be allowed as well.  The VCS is also a means to store
> >human-readable comments.
> >
> >Another piece of [meta]data that a flat tarball lacks is authorship
> >information.
> >
> I infer from this you think projects without a public VCS (postfix is an 
> example) belong in non-free?

At this moment, not yet.  Obviously, old projects didn't even _have_ a VCS,
and I'm not proposing imposing a VCS workflow on the upstream.  I'd like to
consider, at some point in the future, hidden private VCSes where the upstream
occassionally releases a tarball of to be non-free, just like the same PNG
image can be free if there's no XCF file but is not if the upstream holds a
private XCF version they routinely modify -- a "preferred form for
modification" is not required to be good, merely no worse than what upstream
themselves use.

What I'm proposing today is to let upstreams demand no freeness regressions,
in the spirit of my understanding of the GPL.

And while we don't have 3.0 (git) yet, I argue that a technical solution of
requiring a link to a public git service (assuming no extraordinary needs on
the recipient's side), while not very good, meets GPL3 and sort of GPL2.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄

Do we want to try to find consensus before a GR?

[Sam Hartman]

I had been hoping to start some discussions on these issues after
debconf.

I am not really interested in doing so against the backgdrop of a
potential GR happening at the same time.


Thomas, would you be willing to hold off on potential GR stuff until
after I see where we get with consensus?

Folks here, would you rather me try and find out how far we can get on
debian-devel using methodology similar to the debhelper discussions, or
would you rather Thomas draft GR text and look for seconds?

--Sam

Re: Upstream metadata to help our users contribute back to projects we redistribute.

[Xavier]

Hi,

pkg-js-tools embeds a tool that generates debian/upstream/metadata for Github 
repositories (github-missing-upstream).

dpt from pkg-perl-tools uses this file to link locally upstream repo in "git 
remote"



Le 25 juillet 2019 16:17:13 GMT+02:00, Felipe Sateler  a 
écrit :
>On Thu, 25 Jul 2019 17:27:51 +0900, Charles Plessy wrote:
>
>> Hello everybody,
>
>Hello Charles,
>
>> 
>> (posted on -project because of the context, but answers probably
>belong
>> to -devel, where I am not subscribed...)
>> 
>> there is an intersting discussion going on about Git and the
>preferred
>> form for modification of the programs we redistribute.
>> 
>> Indeed, as of today would be hard to say « just run “apt-get source
>> ” and voilà, you can hack and contribute back upstream
>».
>> 
>> There has been now and in the past (for instance when discussing the
>> proposed format “3.0 (Git)” for dpkg) some important points raised
>> explaining the challenge of redistributing the upstream VCS instead
>of a
>> flat file archive.
>> 
>> This is why some packges are shipping metadata indicating where to
>find
>> the upstream sources, send upstream bugs, or even where to dontate
>> money, in order to help our users contribute back to the developement
>of
>> the software that Debian is made of.
>
>Are there tools that are actively using this information?
>Unfortunately, 
>the links you quote below do not provide much information about where 
>this information is used (other than bibref table in UDD).
>
>On the other side of the coin, are there any tools that help generate 
>this metadata? For example, github-hosted projects can have their Bug-
>Database, Bug-Submit, Changelog, Repository, Repository-Browse 
>automatically derived.
>
>-- 
>Saludos,
>Felipe Sateler

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: Upstream metadata to help our users contribute back to projects we redistribute.

[Felipe Sateler]

On Thu, 25 Jul 2019 17:27:51 +0900, Charles Plessy wrote:

> Hello everybody,

Hello Charles,

> 
> (posted on -project because of the context, but answers probably belong
> to -devel, where I am not subscribed...)
> 
> there is an intersting discussion going on about Git and the preferred
> form for modification of the programs we redistribute.
> 
> Indeed, as of today would be hard to say « just run “apt-get source
> ” and voilà, you can hack and contribute back upstream ».
> 
> There has been now and in the past (for instance when discussing the
> proposed format “3.0 (Git)” for dpkg) some important points raised
> explaining the challenge of redistributing the upstream VCS instead of a
> flat file archive.
> 
> This is why some packges are shipping metadata indicating where to find
> the upstream sources, send upstream bugs, or even where to dontate
> money, in order to help our users contribute back to the developement of
> the software that Debian is made of.

Are there tools that are actively using this information? Unfortunately, 
the links you quote below do not provide much information about where 
this information is used (other than bibref table in UDD).

On the other side of the coin, are there any tools that help generate 
this metadata? For example, github-hosted projects can have their Bug-
Database, Bug-Submit, Changelog, Repository, Repository-Browse 
automatically derived.

-- 
Saludos,
Felipe Sateler

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Scott Kitterman]

On July 25, 2019 9:46:08 AM UTC, Vincent Bernat  wrote:
> ❦ 24 juillet 2019 21:29 +00, Scott Kitterman :
>
 This entire discussion feels to me like a small group of developers
 trying to tell the rest of us "my way or the highway". We are
 perfectly capable of phasing out obsolete workflows without a
>hammer
 like a GR (remember dpatch).
>>>
>>>Without a GR, the outcome is decided by a shouting contest. A GR
>seeems
>>>great to know if people are a majority or not.
>>
>> 50% + 1 of developers mandating details like this to 50% - 1 of
>> developers is a horrible way to solve problems like this.
>
>Still better than 10% mandating details like this to 90%.
>
>> If you want people to do things a certain way, have it solve problems
>> that cause people to decide they want to use it. Once you get rough
>> consensus on the new way, change policy.
>
>So, this is the shouting contest. A few people can post messages and
>make it appear there is no consensus.

Usually consensus doesn't magically appear.  It takes work.  At this juncture 
none exists.  The idea of solving this via GR seems to me like an attempt to 
avoid doing that work.

I'm curious who from amongst those pushing for this is volunteering to put all 
the QA maintained packages in git (or should those be removed)?  If you are 
going to mandate this, then I think those are the only two options.

Scott K

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Vincent Bernat]

 ❦ 24 juillet 2019 21:29 +00, Scott Kitterman :

>>> This entire discussion feels to me like a small group of developers
>>> trying to tell the rest of us "my way or the highway". We are
>>> perfectly capable of phasing out obsolete workflows without a hammer
>>> like a GR (remember dpatch).
>>
>>Without a GR, the outcome is decided by a shouting contest. A GR seeems
>>great to know if people are a majority or not.
>
> 50% + 1 of developers mandating details like this to 50% - 1 of
> developers is a horrible way to solve problems like this.

Still better than 10% mandating details like this to 90%.

> If you want people to do things a certain way, have it solve problems
> that cause people to decide they want to use it. Once you get rough
> consensus on the new way, change policy.

So, this is the shouting contest. A few people can post messages and
make it appear there is no consensus.
-- 
Document your data layouts.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Upstream metadata to help our users contribute back to projects we redistribute.

[Charles Plessy]

Hello everybody,

(posted on -project because of the context, but answers probably
belong to -devel, where I am not subscribed...)

there is an intersting discussion going on about Git and the preferred
form for modification of the programs we redistribute.

Indeed, as of today would be hard to say « just run “apt-get source
” and voilà, you can hack and contribute back upstream ».

There has been now and in the past (for instance when discussing the
proposed format “3.0 (Git)” for dpkg) some important points raised
explaining the challenge of redistributing the upstream VCS instead of a
flat file archive.

This is why some packges are shipping metadata indicating where to find
the upstream sources, send upstream bugs, or even where to dontate
money, in order to help our users contribute back to the developement
of the software that Debian is made of.

For many of you, I am sure that it is only a reminder.  But in any case
please have a look at https://wiki.debian.org/debian/upstream and
https://wiki.debian.org/AppStream for details.

Have a nice day,

Charles

-- 
Charles Plessy  Tsurumi, Kanagawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy