[Dev] Policy for Package Quarantines

[Nicolás A. Ortega]

On Fri, Apr 14, 2017 at 09:36:25PM -0400, Luke Shumaker wrote:
> On Fri, 14 Apr 2017 18:28:50 -0400,
> Nicolás A. Ortega wrote:
> > My proposal is the following: when someone brings up a freedom issue (or
> > even privacy, for that matter) they should also links to the information
> > that lead them to this conclusion, once we see that these links have
> > something behind them (a quick skim through the links) we can put in
> > place the temporary quarantine of the package. After this point all
> > information regarding the freedom issues with the package should be
> > concentrated in one place (public place where everyone can see it) and a
> > more thorough investigation of the matter (finding exact files that are
> > non-free) should take place. If no actual evidence is found or the
> > evidence has *all* been countered after X amount of time (I think a
> > month or two should do) then the package is taken out of quarantine
> > until more concrete evidence can be found. If evidence is found and
> > cannot be countered then the package is labelled permanently as non-free
> > until either upstream fixes the freedom issues (which *should be
> > reported to upstream when found*) or we create a -libre package for it.
> 
> As attractive as that proposal is, it doesn't allow for quickly
> handling uncontroversially nonfree packages.
> 

I don't see why not, someone will end up being affected and that person
will take interest in why the package was removed. Either way, the main
idea is that there should be a single place where all the evidence is
accumulated.

Also, the uncontroversial non-free packages tend to be either small
packages (which can be easily verified if they are non-free, therefore
the process I suggested shouldn't take too long) or simply not even
source available (meaning that there's no question about the freeness of
the software). This would also help us to get into the habit of
providing proper evidence even if it may seem obvious to us. I still
think that a concentrated place should be created for this.

> And really, the Parabola dev community hasn't generally been receptive
> to big ol' processes they have to step through.
> 

They may not be, but being organized will help in the long-run as
Parabola becomes a larger project. The bigger you get the more chaotic
it will be when trying to solve these issues (imagine these mailing
lists where it isn't only the same ~10 people responding).

> > The most important thing I want to be taken away from this is that
> > information on the freedom issues of a package should be *easily
> > available*. I shouldn't have to be asking absolutely everyone in the
> > community who has the actual links so I can verify for my own eyes.
> > What's more, the more eyes we have on the issue the more information we
> > can obtain and the faster we can solve things.
> 
> qt5-webengine was actually one of the better cases.  There have been
> packages blacklisted with *no* public discussion or documentation (for
> example, libglvnd).
> 
> In blacklist.txt, there is a field for a 'ref' referencing Debian,
> LibrePlanet, Savannah, Fedora, or Parabola (our bug tracker), for
> where you can read about justification for it being blacklisted.
> 
> Perhaps we should make this field mandatory?
> 

I have looked at this field many times for many packages and I often
don't see any links, but only accusations. This would be fine if we knew
that you could visit a page on the website where we all knew the
information was available, however that does not exist. If we want the
blacklist.txt to be the official place for putting this information
(which I don't recommend since it's not completely accessible to
absolutely everyone to edit in case of new evidence) it should contain
much more detailed information than what I have seen.

What's more, having this policy also creates an easy way for new
contributors to get their foot in the door, since this is something
somewhat easy to comprehend and only requires some research.

-- 
Nicolás Ortega Froysa (Deathsbreed)
https://themusicinnoise.net/
http://uk7ewohr7xpjuaca.onion/
Public PGP Key:
https://themusicinnoise.net/deathsbreed@themusicinnoise.net_pub.asc
http://uk7ewohr7xpjuaca.onion/deathsbreed@themusicinnoise.net_pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20170415/7f27df10/attachment.sig>