Gentoo Archives: gentoo-dev

From: hasufell <hasufell@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/microcode-ctl/
Date: Wed, 12 Aug 2015 10:11:17
Message-Id: 55CB1BB7.1030702@gentoo.org
In Reply to: Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/microcode-ctl/ by Andrew Savchenko
1 On 08/12/2015 08:48 AM, Andrew Savchenko wrote:
2 > On Tue, 11 Aug 2015 13:17:10 +0200 hasufell wrote:
3 >> On 08/11/2015 08:34 AM, Mike Frysinger wrote:
4 >>> commit: 719cc5ef240b766953ddbe1e7a6593f8091eed12
5 >>> Author: Mike Frysinger <vapier <AT> gentoo <DOT> org>
6 >>> AuthorDate: Tue Aug 11 06:28:16 2015 +0000
7 >>> Commit: Mike Frysinger <vapier <AT> gentoo <DOT> org>
8 >>> CommitDate: Tue Aug 11 06:34:22 2015 +0000
9 >>> URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=719cc5ef
10 >>>
11 >>> microcode-ctl: stop installing the init script
12 >>>
13 >>> Updating microcode on the fly is dangerous as it can modify the set of
14 >>> valid instructions. An active example of this is Intel's TSX insns --
15 >>> the latest microcode push disables the insn on newer CPUs and causes
16 >>> SIGILL when you try to use it. But if you test for the insn before the
17 >>> microcode is updated, it will execute fine. For daemons that launched
18 >>> before the update, they'll find the flag works, and then crash later on
19 >>> when the insn no longer exists.
20 >>>
21 >>> Thus the only safe way to update microcode is at boot time via a builtin
22 >>> initramfs. Details on this operation can be found in #528712#41.
23 >>>
24 >>
25 >> I've already asked you twice on the ML why you keep ignoring the
26 >> standard we set for the commit message summary and pretty much everyone
27 >> is following except you.
28 >
29 > Let me remind you that:
30 > 1. this is not a standard, but a draft;
31 > 2. not all issues are clear right now (e.g. how to reference bugs);
32 > 3. it is not approved by the Council;
33 > 4. not everyone agrees with these rules anyway.
34 >
35
36 So you want to sabotage consistency and wait until the council approves
37 every minor detail that has been worked out by the community? These
38 things WERE discussed (half a year ago or more) and there was consensus.
39 Things that are still not clear (such as referencing bug reports) were
40 not added to the wiki. Don't mix things up.
41
42 If we say everyone is allowed to ignore all the rules as long as it
43 repoman-checks, then I don't know why I even keep throwing out
44 discussions, emails and editing the wiki. Commit message format is
45 really not a workflow-limiting thing. I don't know why you complain like
46 that.
47
48 And vapier has not participated much in that discussion and has not
49 expressed his interest in a different format. So how is anyone supposed
50 to react to that?
51
52 This is not constructive.

Replies