unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 27264@debbugs.gnu.org
Subject: bug#27264: gnome-shell-3.24.2 consistently dies during initialization
Date: Sun, 11 Jun 2017 04:57:32 -0400	[thread overview]
Message-ID: <874lvm52bn.fsf@netris.org> (raw)
In-Reply-To: <87lgp2p5pv.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Thu, 08 Jun 2017 22:47:08 +0200")

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> 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 sympathize, and I agree that it sucks.
>
> Now, I think we are all guilty.  Rather than trying to find someone to
> blame, I’m more interested in seeing why we got there and what we can do
> to avoid it in the future.  Of course we can call for GNOME users to
> test it, and we’ll surely do that explicitly in the future.  But IMO we
> should be thankful to those who worked on this upgrade branch,

I agree that we should be thankful, and I'm sorry for not saying so in
my last message.  I'm very grateful to Marius and Kei for their
excellent work upgrading GNOME to 3.24.  I handled the upgrade to 3.22,
so I know how much work that is, and I'm glad to have been spared the
effort this time around.  I'm also grateful to Marius, Kei, and Roel for
their work on the final commits to get GNOME working.

Finding someone to blame is not my goal.  Like you, my goal is to avoid
this mistake in the future.  I don't see how to do that without calling
attention to the mistake and labeling it as such.  I did not mention any
names in my complaint.

>                                                                and I
> feel it would be unwise to sit back and add more on their shoulders.

It is not my intent to add more to anyone's shoulders.  I'm not asking
anyone to do anything.  I'm asking people *not* to do something.  I'm
asking people not to merge major upgrade branches without testing them
first.  Merging major upgrade branches is not something that should be
done without sufficient care.  If you aren't able to do the job
carefully, then don't do it.  That's not adding to anyone's shoulders.
No one is imposing deadlines on us, and this was not a security update.

I'm not sure why you think "we are all guilty".  Is it because we have a
collective responsibility to merge 'staging' more quickly than would be
possible if we waited for someone to test it first?  If so, I disagree.

On the contrary, I believe we have a responsibility to make sure major
upgrade branches are tested before they are merged, because a broken
'master' effectively means that we cannot deploy security updates to
users until the problem is fixed.

Does that make sense?

       Mark

  reply	other threads:[~2017-06-11  8:58 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-06  4:59 bug#27264: gnome-shell-3.24.2 consistently dies during initialization Mark H Weaver
2017-06-07 10:37 ` Ludovic Courtès
2017-06-07 13:15   ` Roel Janssen
2017-06-07 21:58     ` Mark H Weaver
2017-06-08  6:03       ` Marius Bakke
2017-06-08  6:29         ` Mark H Weaver
2017-06-08 12:35           ` Kei Kebreau
2017-06-08 16:13           ` Marius Bakke
2017-06-08 16:29             ` Marius Bakke
2017-06-09  6:23               ` Chris Marusich
2017-06-09  7:02               ` Mark H Weaver
2017-06-08  7:39         ` Ben Sturmfels
2017-06-08  6:48       ` pelzflorian (Florian Pelz)
2017-06-08 12:01       ` Ludovic Courtès
2017-06-08 12:23         ` Kei Kebreau
2017-06-08 13:09           ` Roel Janssen
2017-06-08 18:08           ` Roel Janssen
2017-06-08 18:34             ` Kei Kebreau
2017-06-08 14:01         ` Mark H Weaver
2017-06-08 14:54           ` Chris Marusich
2017-06-08 17:08           ` Leo Famulari
2017-06-08 17:19             ` Marius Bakke
2017-06-08 17:29             ` Catonano
2017-06-08 17:45               ` Leo Famulari
2017-06-08 18:12             ` Leo Famulari
2017-06-08 20:47           ` Ludovic Courtès
2017-06-11  8:57             ` Mark H Weaver [this message]
2017-06-11 13:16               ` Ludovic Courtès
2017-06-08 14:20         ` pelzflorian (Florian Pelz)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874lvm52bn.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=27264@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).