Subject: bug#53533: closed ([DISCUSSION] Quality of services in reproducible build environment Guix)

From: [email-masked] (GNU bug Tracking System)
Date: Mon, 24 Jun 2024 21:34:02 +0000

Your bug report

#53533: [DISCUSSION] Quality of services in reproducible build environment Guix

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
53533: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53533
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: [DISCUSSION] Quality of services in reproducible build environment Guix
From: Sharlatan Hellseher <[email-masked]>
To: [email-masked]
Date: Mon, 24 Jun 2024 22:31:53 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Subject: [DISCUSSION] Quality of services in reproducible build environment Guix
From: Sharlatan Hellseher <[email-masked]>
To: [email-masked]
Date: Tue, 25 Jan 2022 20:45:22 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

Hi Guix team!

The current QA for the accepted changes in Gujx is far away from
trustible. For example, some
changes in package update may cause a faileur of the whole chain of
packages depending on it. It
would be nice to have some soft policy of changes, check list or some
procedure to have a "stable"
branch which may guarantee all packages build successfully and pass of
all enabled tests.

I find current [[id:60941898-0ed4-4188-b473-d2dcda158d61][CI/CD]]
(https://ci.guix.gnu.org/) is missleading in case of providing some
visibility
of all successful builds for the current pushed changes (on master
branch). I would like to conclude
from the CI is which commit broke how many packages. Other open
question - if I've sticked to a
specific "stable" branch how I may be sure that another ~guix pull~
will not break my packages in
case of un-pinned version?

Some missing features of CI
- Timing - current view has missing a clear representation of build date-time
- Overall slats for the current commit to the specific branch - and
how many package are become
  broken after update of package X.
- Sort of "blocking on merge" of a commit which causes some issues (do
not merge broken packages
  into stable branch)
- Some documentation for all UI features (green dots, red dots, grey dots etc.
  https://ci.guix.gnu.org/eval/54326/dashboard)

Some missing practice of packaging:
- Some essential message of the reason why tests were disabled and any
sort of suggestions on how to
  make them enabled. Contact upstream if required.
- Before sending patch make sure (at least for the localhost
architecture) it's built, linted and in
  case of bumping version - all dependent chain still can be built.

Related commits and issues which broke other packages in ~master~ branch:
- https://issues.guix.gnu.org/53230
- fix 6445f412b993ec7b52dc4c81e99f49af38b3a967 RawTherapee stopped
building with wrong configure key,
  the previous update to 5.8 was never tested before been merged.

  #+begin_src sh
git checkout master
git pull
git log -n1 --pretty="%h %s %cd - %cn"
  #+end_src
  : 4235c6ee92 gnu: QGIS: Build without QtWebKit. Tue Jan 25 15:10:19
2022 -0500 - Leo Famulari

  Excess changes which could be prevented with just local attempt to build
  #+begin_src sh
git log --grep="Fix build" --pretty="%h %s %cd - %cn" | wc -l
  #+end_src
  : 1025

-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.