bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Chris Marusich <cmmarusich@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2849 bytes --]

Mark H Weaver <mhw@netris.org> 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.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]