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