Bug#984497: weasels and doves

[Albert van der Horst]

> Op 08-03-2021 17:36 schreef Andrius Merkys :
> 
>  
> Hi,
> 
> On 2021-03-08 15:44, Albert van der Horst wrote:
> > I don't see the problem here. If there is a bug in an old version supplied 
> > with Debian, the bug report lands with Debian. 
> 
> Not necessary. Many users cannot tell whether a bug is caused by
> upstream code or Debian packaging. Many users do not know about Debian
> BTS. Thus Debian-specific bugs land in upstream trackers, and some
> upstreams do not want to provide support outside what they consider
> "canonical" use of their software.

This surprises me. I use Debian for reliability. I expect the 
Debian package more reliable than whatever upstream supplies.
So I would file a bug in the Debian system. 
I also expect that Debian wants to know the bugs of all packages,
not just "Debian-specific" in order to remove packages of low quality. Maybe my 
esteem/expectation of Debian is too high ...
> 
> > Then Debian can solve the bug report by renewing upstream. Sot that bug 
> > report is not against the package, but against the packaging.
> 
> True, but this might be slowed down by the update process in stable.
Right, but then bugs against a stable version should be rare.
> 
Definitive fixing maybe. But if I have a problem and stable I
can always load a fixed version from test. 



I can now see that bleeding edge developpers, who are fast moving
and generating many bugs, will want to keep out of Debian.
But why would Debian want them in? Anywhere, obviously it is best
to grant their wish, even if they have no legal standing.
FOSS is FOSS, right?

> Best,

> Andrius

Groetjes Albert

Bug#984497: weasels and doves

[Andrius Merkys]

On 2021-03-10 02:38, George N. White III wrote:
> On Mon, 8 Mar 2021 at 12:36, Andrius Merkys  > wrote:
> Many users will not look into e-mail addresses. They will search online
> using the name of the software, and will arrive at the same developers'
> desk. This might be offset by renaming entire pieces of software, but
> renamed packages become hardly visible and all valuable online material
> related to the original name becomes hidden from users.
> 
> Renaming should be like "debian-sid-" for supported 
> by Debian packages.

I assume your suggestion is to keep such packages sid-only. Apart from
compilers/build systems (sbt and bazel, to name a few), I am not sure
about the benefit of sid-only packages.

> There are, however, use-cases where packaging is not
> helpful to users:
> 
> 1. a package that relies on "customized" configurations of widely used
> libraries
> (hdf4 and gdal are examples of libraries with many optional extensions).
> 
> 2. a package whose purpose is to provide highly optimized versions of common
> libraries for low volume hardware (such as large HPC systems).   There are
> many potential hardware configurations with new configurations being
> released
> multiple times a year.   There are complicated issues of reproducibility
> and
> testing that don't have one size fits all answers.

This problem is general, not limited to software whose developers object
inclusion in Debian.

Andrius

Bug#984497: weasels and doves

[George N. White III]

On Mon, 8 Mar 2021 at 12:36, Andrius Merkys  wrote:

> Hi,
>
> On 2021-03-08 15:44, Albert van der Horst wrote:
> > I don't see the problem here. If there is a bug in an old version
> supplied with Debian, the bug report lands with Debian.
>
> Not necessary. Many users cannot tell whether a bug is caused by
> upstream code or Debian packaging. Many users do not know about Debian
> BTS. Thus Debian-specific bugs land in upstream trackers, and some
> upstreams do not want to provide support outside what they consider
> "canonical" use of their software.
>
> > Then Debian can solve the bug report by renewing upstream. Sot that bug
> report is not against the package, but against the packaging.
>
> True, but this might be slowed down by the update process in stable.
>
> > If it persists in the newest version, the bug can be passed to
> > upstream.
>
> Again - if the report ends up in Debian BTS.
>
> > Bug reports will not land at the developpers desk, or Debian has to take
> measures that they don't, e.g. by replacing e-mail addresses. No reasonable
> upstream developer will object to such an arrangement.
>
> Many users will not look into e-mail addresses. They will search online
> using the name of the software, and will arrive at the same developers'
> desk. This might be offset by renaming entire pieces of software, but
> renamed packages become hardly visible and all valuable online material
> related to the original name becomes hidden from users.
>

Renaming should be like "debian-sid-" for supported
by Debian packages.   There are, however, use-cases where packaging is not
helpful to users:

1. a package that relies on "customized" configurations of widely used
libraries
(hdf4 and gdal are examples of libraries with many optional extensions).

2. a package whose purpose is to provide highly optimized versions of common
libraries for low volume hardware (such as large HPC systems).   There are
many potential hardware configurations with new configurations being
released
multiple times a year.   There are complicated issues of reproducibility
and
testing that don't have one size fits all answers.

-- 
George N. White III

Bug#984497: weasels and doves

[Andrius Merkys]

Hi,

On 2021-03-08 15:44, Albert van der Horst wrote:
> I don't see the problem here. If there is a bug in an old version supplied 
> with Debian, the bug report lands with Debian. 

Not necessary. Many users cannot tell whether a bug is caused by
upstream code or Debian packaging. Many users do not know about Debian
BTS. Thus Debian-specific bugs land in upstream trackers, and some
upstreams do not want to provide support outside what they consider
"canonical" use of their software.

> Then Debian can solve the bug report by renewing upstream. Sot that bug 
> report is not against the package, but against the packaging.

True, but this might be slowed down by the update process in stable.

> If it persists in the newest version, the bug can be passed to 
> upstream.

Again - if the report ends up in Debian BTS.

> Bug reports will not land at the developpers desk, or Debian has to take 
> measures that they don't, e.g. by replacing e-mail addresses. No reasonable 
> upstream developer will object to such an arrangement.

Many users will not look into e-mail addresses. They will search online
using the name of the software, and will arrive at the same developers'
desk. This might be offset by renaming entire pieces of software, but
renamed packages become hardly visible and all valuable online material
related to the original name becomes hidden from users.

Best,
Andrius

Bug#984497: weasels and doves

[Dima Kogan]

Albert van der Horst  writes:

> I don't see the problem here. If there is a bug in an old version
> supplied with Debian, the bug report lands with Debian. Then Debian
> can solve the bug report by renewing upstream. Sot that bug report is
> not against the package, but against the packaging. If it persists in
> the newest version, the bug can be passed to upstream. Bug reports
> will not land at the developpers desk, or Debian has to take measures
> that they don't, e.g. by replacing e-mail addresses. No reasonable
> upstream developer will object to such an arrangement.

Sure they can. Developers want users to think that their software is
cool. By distributing stuff in Debian, upstream gets less control in
that, and users may think that the software sucks due to no fault of
upstream.

This particular project is fast-moving, so users of the package would at
best have a functional-yet-old version, and may think the software
sucks. *I* don't agree, and *I* think working with and using a distro is
still worth it. But this upstream made their preferences clear, and I
think we should respect them.

Bug#984497: weasels and doves

[Albert van der Horst]

I don't see the problem here. If there is a bug in an old version supplied with 
Debian, the bug report lands with Debian. 
Then Debian can solve the bug report by renewing upstream. Sot that bug report 
is not against the package, but against the packaging.
If it persists in the newest version, the bug can be passed to 
upstream.
Bug reports will not land at the developpers desk, or Debian has to take 
measures that they don't, e.g. by replacing e-mail addresses. No reasonable 
upstream developer will object to such an arrangement.

Groetjes Albert

> Op 06-03-2021 12:58 schreef Geert Stappers :
> 
>  
> Preamble:
>Do know that having own priorities
>and working together IS possible.
> 
> 
> On Sat, Mar 06, 2021 at 10:17:03AM +0800, Paul Wise wrote:
> > On Fri, 2021-03-05 at 16:52 +0100, Andreas Tille wrote:
> > 
> > > Finally the license statement is all about redistribution ... and
> > > than upstream says:  Do not redistribute. 
> > 
> > They appear to be fine with redistribution,
> 
> OK
> 
> 
> > just not with wide distribution by a popular Linux distribution,
> > which has a stable release that is guaranteed to get out of date with
> > documentation.
> 
> Rendering that to FUD does allow me to add more FUD.
> Less agressive:
>   The _possible_ burden on upstream
>   should NOT block our wish to package it.
> 
>  
> > Possibly they could be convinced by having the package only available
> > in Debian unstable or experimental and guaranteeing to keep it up to
> > date with the latest available upstream version.
>  
> Good relation with upstream is indeed preferred.
> That relation will only exist when packaging is going on.
> We are dealing with libre software.  It implies that
> upstream is libre to express "we don't want that it happens",
> we are libre to do packaging.
> Restricting ourselfs to only unstable feels wrong.
> 
> 
> > On the other hand they probably also don't want to deal with bug
> > reports about a build that they did not produce.
> 
> Double you tee ef.
> Please keep Fear Uncertainty and Doubt to yourself.
> Now breaking that rule:
> 
>   Shady generated binaries are plain evil.
> 
> 
> 
> (Back to more reasonable)
> 
> It is not to us, Debian, to come with possible reasons
> why upstream is "right" in blocking us.
> 
> We, Debian, are fully aware that packaging comes
> with responsebilities to quality.
> 
> 
>  
> > Perhaps the right way is for Debian to distribute ExplosionAI software
> > under different names with all documentation pointing at Debian to
> > avoid upstream having to deal with bug reports from Debian users.
> 
> 
> Same as was done with Iceweasel and Icedove.
> 
> Future history will tell which lessons were learnt.
> 
> 
> 
> Groeten
> Geert Stappers
> DD
> -- 
> Silence is hard to parse

Bug#984497: weasels and doves

[Geert Stappers]

Preamble:
   Do know that having own priorities
   and working together IS possible.


On Sat, Mar 06, 2021 at 10:17:03AM +0800, Paul Wise wrote:
> On Fri, 2021-03-05 at 16:52 +0100, Andreas Tille wrote:
> 
> > Finally the license statement is all about redistribution ... and
> > than upstream says:  Do not redistribute. 
> 
> They appear to be fine with redistribution,

OK


> just not with wide distribution by a popular Linux distribution,
> which has a stable release that is guaranteed to get out of date with
> documentation.

Rendering that to FUD does allow me to add more FUD.
Less agressive:
  The _possible_ burden on upstream
  should NOT block our wish to package it.

 
> Possibly they could be convinced by having the package only available
> in Debian unstable or experimental and guaranteeing to keep it up to
> date with the latest available upstream version.
 
Good relation with upstream is indeed preferred.
That relation will only exist when packaging is going on.
We are dealing with libre software.  It implies that
upstream is libre to express "we don't want that it happens",
we are libre to do packaging.
Restricting ourselfs to only unstable feels wrong.


> On the other hand they probably also don't want to deal with bug
> reports about a build that they did not produce.

Double you tee ef.
Please keep Fear Uncertainty and Doubt to yourself.
Now breaking that rule:

  Shady generated binaries are plain evil.



(Back to more reasonable)

It is not to us, Debian, to come with possible reasons
why upstream is "right" in blocking us.

We, Debian, are fully aware that packaging comes
with responsebilities to quality.


 
> Perhaps the right way is for Debian to distribute ExplosionAI software
> under different names with all documentation pointing at Debian to
> avoid upstream having to deal with bug reports from Debian users.


Same as was done with Iceweasel and Icedove.

Future history will tell which lessons were learnt.



Groeten
Geert Stappers
DD
-- 
Silence is hard to parse


signature.asc
Description: PGP signature