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

[Leo Famulari <leo@famulari.name>]

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

On Thu, Jun 08, 2017 at 10:01:56AM -0400, Mark H Weaver wrote:
> I'm annoyed that I've been forced to either use a different desktop
> environment in the meantime or else sacrifice security updates.  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.
> 
> 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 with your points. For complex interactive software, someone must
test it by actually using it. And we should remember that the master
branch is supposed to always be "deployable", and choose to test
breaking changes on other branches.

> 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.

It's true, we could not even think of pushing untested or lightly-tested
changes if we couldn't roll-back.

But, if we want to 1) receive updates to big software suites like GNOME,
and we want to 2) avoid breakage on the master branch, we *need* more
testers.

As somebody who has helped with a few of these branches so far, the lack
of assistance with testing and bug fixes is a major problem. I rarely
feel as confident as I'd like before pushing the merge. More than once
I've merged a major branch with the impression that only myself and 1 or
2 other people have actually deployed it on their workstation or in a
staging environment that precedes production.

There is a large number of contributors adding new packages or working
on features, but almost nobody helps test big changes or other boring
and tedious maintenance tasks. So, those things suffer, and we end up
testing on the master branch. I don't have any potential solutions in
mind. As we are mostly volunteers with limited time and computing
resources, we can only do so much.

Indeed, I had to sit out this staging cycle due to lack of free time and
computing resources.

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