unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* "random check" approach to Guix QA?
@ 2023-11-20 23:11 Andy Tai
  2023-11-22  9:28 ` Csepp
  2023-12-04 15:55 ` Andreas Enge
  0 siblings, 2 replies; 3+ messages in thread
From: Andy Tai @ 2023-11-20 23:11 UTC (permalink / raw)
  To: guix-devel

Hi, currently Guix QA tries to rebuild all dependent packages impacted
by a change (in majority of cases updates to a new version of a
package).  When there are a large number of dependent packages like
say 500 or 1000 or more, rebuilding all that takes a long time and
often the rebuild cannot complete, leaving the patch submission
dangling with no results.

For some things where safety is important, for example import food
safety, the regulatory authority may use random check or random
sampling as a way to check for safety, in case that there is no
resource to physically check every package.

Can the same approach be borrowed here, so when there is large number
of impacted packages from a patch, say larger than 200, Guix QA just
randomly select a subset sample out of these packages and build them,
and in case of (new) failures ask the submitter to fix the (new)
failure? And repeat this as needed.   This way patches can go thru the
QA process more quickly.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: "random check" approach to Guix QA?
  2023-11-20 23:11 "random check" approach to Guix QA? Andy Tai
@ 2023-11-22  9:28 ` Csepp
  2023-12-04 15:55 ` Andreas Enge
  1 sibling, 0 replies; 3+ messages in thread
From: Csepp @ 2023-11-22  9:28 UTC (permalink / raw)
  To: Andy Tai; +Cc: guix-devel


Andy Tai <atai@atai.org> writes:

> Hi, currently Guix QA tries to rebuild all dependent packages impacted
> by a change (in majority of cases updates to a new version of a
> package).  When there are a large number of dependent packages like
> say 500 or 1000 or more, rebuilding all that takes a long time and
> often the rebuild cannot complete, leaving the patch submission
> dangling with no results.
>
> For some things where safety is important, for example import food
> safety, the regulatory authority may use random check or random
> sampling as a way to check for safety, in case that there is no
> resource to physically check every package.
>
> Can the same approach be borrowed here, so when there is large number
> of impacted packages from a patch, say larger than 200, Guix QA just
> randomly select a subset sample out of these packages and build them,
> and in case of (new) failures ask the submitter to fix the (new)
> failure? And repeat this as needed.   This way patches can go thru the
> QA process more quickly.

I think it should always do that.  Assign a weight to all derivations
that have to be built and choose from them randomly.
Could use a combination of dependents and estimated build time to comput
the weight.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: "random check" approach to Guix QA?
  2023-11-20 23:11 "random check" approach to Guix QA? Andy Tai
  2023-11-22  9:28 ` Csepp
@ 2023-12-04 15:55 ` Andreas Enge
  1 sibling, 0 replies; 3+ messages in thread
From: Andreas Enge @ 2023-12-04 15:55 UTC (permalink / raw)
  To: Andy Tai; +Cc: guix-devel

Hello,

Am Mon, Nov 20, 2023 at 03:11:29PM -0800 schrieb Andy Tai:
> Can the same approach be borrowed here, so when there is large number
> of impacted packages from a patch, say larger than 200, Guix QA just
> randomly select a subset sample out of these packages and build them,
> and in case of (new) failures ask the submitter to fix the (new)
> failure? And repeat this as needed.   This way patches can go thru the
> QA process more quickly.

notice that this approach requires to build a complete connected subgraph
starting with the changed package, so simple random sampling will not work.

For instance, if B depends on A, then C_1 to C_1000 depend on B, one needs
to always include B. Or if B_1 depends on A, B_2 on B_1, and so on until
B_1000 depends on B_999, one would need to only build a few steps
on the path.

Maybe it would make sense, one day when we have lots of idle build
power, to start by building at least the immediate dependents to get
an idea?

Andreas



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-12-04 15:56 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-11-20 23:11 "random check" approach to Guix QA? Andy Tai
2023-11-22  9:28 ` Csepp
2023-12-04 15:55 ` Andreas Enge

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).