From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: bug#27264: gnome-shell-3.24.2 consistently dies during initialization Date: Thu, 08 Jun 2017 07:54:21 -0700 Message-ID: <871squ8r8i.fsf@gmail.com> References: <87o9u13e4i.fsf@netris.org> <8760g8t769.fsf@gnu.org> <87shjbwjdc.fsf@netris.org> <87ink6zo19.fsf@gnu.org> <87vao6poh7.fsf@netris.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41283) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dIyq3-00044z-Pj for bug-guix@gnu.org; Thu, 08 Jun 2017 10:55:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dIypz-0002L8-Tm for bug-guix@gnu.org; Thu, 08 Jun 2017 10:55:07 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:60787) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dIypz-0002L0-Q4 for bug-guix@gnu.org; Thu, 08 Jun 2017 10:55:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dIypx-00005O-Nk for bug-guix@gnu.org; Thu, 08 Jun 2017 10:55:03 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87vao6poh7.fsf@netris.org> (Mark H. Weaver's message of "Thu, 08 Jun 2017 10:01:56 -0400") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Mark H Weaver Cc: 27264@debbugs.gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Mark H Weaver writes: >>> I have a question: Does GNOME 3 work for *anyone* in Guix now? If so, >>> that would be useful information. If not, I wonder why this got merged >>> into master. I just updated my system, and I observe the same problem. >> an automated test that logs in, takes a screenshot, and does some OCR >> to check whether we got something that looks like a GNOME screen. > > I think this is unacceptable. The test you propose above is no where > near adequate to assure that the updated desktop environment is usable > for real work. It would be better than nothing, since it would catch catastrophic errors, but you're right: it's no substitute for thorough testing. I think it would be good to have basic sanity tests, and I agree that changes to the desktop environments ought to be tested before merging. In this case, it's clear that the final result was not tested. > I would never consider pushing such a major update to master without > testing it first. I'm astonished that anyone thinks that this is > acceptable behavior. To really prevent bad updates, a mechanism is required (such as automated tests). A more disciplined release process and an increased willingness by everyone to run the tests can help, too, but a (good) mechanism will be the most reliable, since it wouldn't rely on humans remembering to do the right thing. I think a sanity test that confirms we can at least log in to the various desktop environments would be a good start - but not a total solution. > I'm sorry to be harsh, but I feel justified to air my grievances >because > I believe this is the kind of event that will cause GNOME users to label > GuixSD an experimental distribution that's not suitable for one's > primary work machine, but are too polite to complain. Let me be the > canary in the coal mine. I agree. > While it's true that users can boot into an older generation of their > system in an emergency, and that's a *great* comfort, in general it's > not an acceptable fallback because it entails sacrificing security > updates. I'm concerned that our fallback feature has caused people to > become quite careless with breaking things on our master branch. I think you're right, but I think it's just one reason. Based on what people are saying in this email thread, it sounds like another reason why humans chose not to perform the tests was because the iteration time is perceived as too slow. Maybe if we can think of ways to speed up the testing cycle, people will be less tempted to skip the tests. For example, if there were a way to build a "mostly correct" system in half the time (presumably, by somehow avoiding the actual builds required), that might encourage people to test their work more frequently. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlk5ZR4ACgkQ3UCaFdgi Rp1yqBAAmaTBlVbc1gEJ/pel1uZeqlnTnpP8Xp/oZx1F4jMUC26qyEXOzLtWJKqo JSYO9IBN1QcPtU9RovWPp1e0mi0lA1DDhbW9X/ilAvVbq9xVKypnfRnC+03JMRyk rhQ+m+8q/vuLyWajtTtc56VUoKGphf8k5czzJ0SKLGkOOLlOQDNXVH5Ju7B0Skg4 R39+xmLHAcgwDOwzpf1eUG3fkC8rISB+15lRHh4THht0f1TF716Tqg/ouFI/m7BU jxYNx29c/XdDMFET2E7xX5vr9uY4OzfG4THJxIKe3phboFdwBuRjrlNarP7nwljm +mYufVP+lVS/Q/wf5vuwtrmPwfWW1NwQ9qdv+rPxJwKjEWp9wb7RCQjFb1kM9TlX GYcwn1Pkrb+rUoMVSQBfGEQXbSEVJcFb5rNlQuFAPUw3tzXy9jznG7n9y+g3HXbH FSrG77vvE1ONq8V/NBb62+ZStPhHe8TXCRsJ27TgZ+78ZWdN1QBBKraKn89sJNVH 5/cnZtGFqcT6VWCzqr1aOc2sLOF8PO9TN1stcoC3/4/qw54CmNOFcDRmL9PfgMLY jYZ6ygu16nL1GD0ob5zNzSL2bCA9+sg3m+b9Kft8O0drdTLnQKcjj6pLPP1WY9gJ dGuVSdwKV5RUVQ3cooU/mx1WY0WPYdzmUe4SHpbuyNaTsF4ZbHg= =e+l4 -----END PGP SIGNATURE----- --=-=-=--