Re: [GNU-linux-libre] review of uruk

[Denis 'GNUtoo' Carikli]

On Mon, 27 Mar 2023 13:12:54 -0400
bill-auger <bill-auger@peers.community> wrote:

> On Mon, 27 Mar 2023 17:42:02 +0200 Denis wrote:
> > Here the issue is that I fear that no one will commit to do the full
> > review, but small parts were already reviewed by different people  
> 
> no single person needs to commit to do the entire review - one
> person needs to commit to over-see the process, collect the
> findings, manage the checklist, organize the discussions, then
> open a licensing ticket when all is done (and pester the FSF if
> it is ignored for 5 years), and so on
OK.

> i added the review checklist to that page, and moved it out of
> the "incoming" name-space - the page should remain, even after it
> is no longer "incoming", though maybe the extended notes could
> be deleted eventually
> 
> https://libreplanet.org/wiki/Uruk
Thanks a lot.

> On Mon, 27 Mar 2023 17:42:02 +0200 Denis wrote:
> > My main concern here is to find a process that can easily be checked
> > later on by someone else.  
> 
> that was somewhat the idea for the checklist - any detected
> problems should be summarized on the checklist - the wiki
> change history could be reviewed at any later time
Yes, that makes things easier, but the issue is how to trust it not to
have missed too important things.

For instance if someone reviews uruk-cleaner, without contributing to
the free software directory along the way, we'd need to re-do the same
work to check if that review is valid.

Also do we need to review the package or the upstream git? And can
there be discrepancies between both?

Here using the free software directory would help as there is already a
process to take care of reviews by people, and the name of people is
also recorded, so over time people can build reputations through that
system.

So here we can even trust people with specific reputations (like a
reputation to find problematic things in software but do only a quick
review, a reputation to do the review in depth, etc).

So the checks I was talking about were more for this fine grained level.

And here some light automation can be useful too as it could also help
bridging the gap between uruk-cleaner's git and uruk-cleaner's package
(we probably need to review the git for the free software directory and
the package for the FSDG and we want to avoid doing the work twice).

You can also ask questions through code when you have parsable data.
For instance is there any GPLv2-only package that uses OpenSSL as a
dependency? Obviously that won't tell how OpenSSL is used (it could be
through the 'openssl' command line application or by linking to it) so
you'd still need a human in the loop.

And some of the code to ask questions can also be shared, so that work
is then reusable for distributions using the same package managers for
instance.

> notwithstanding, the FSF's "brief final review" of hyperbola
> should have been de-prioritized, queued behind the ones which
> were already fully evaluated by the community
The downside of that could be an even bigger blocking of the process if
my hypothesis is right.

> the point of the 2018 changes and the "brief final review", was
> that the community would do all of the difficult and
> time-consuming work - the FSF only needs to read the mailing
> list messages, and can largely trust the reviewers findings
> the FSF's role needs to be no more than to double-check what
> the "application manager" has documented
The issue here may be precisely the amount of work needed to do this
double-check.

Denis.

pgpyk1ZRDt4lC.pgp
Description: OpenPGP digital signature