1 |
On Wed, Dec 16, 2020 at 11:48 PM desultory <desultory@g.o> wrote: |
2 |
> |
3 |
> On 12/16/20 03:01, Michał Górny wrote: |
4 |
> > On Tue, 2020-12-15 at 23:37 -0500, Aaron W. Swenson wrote: |
5 |
> >> On 2020-12-15 11:16, Michael Orlitzky wrote: |
6 |
> >>> On 12/15/20 11:11 AM, Thomas Deutschmann wrote: |
7 |
> >>>> |
8 |
> >>>> What do you mean exactly? |
9 |
> >>>> |
10 |
> >>>> For Gentoo tooling, only Gentoo keyservers are important and |
11 |
> >>>> Gentoo no longer synchronizes with any other pool. |
12 |
> >>>> |
13 |
> >>> "The Gentoo developer tooling explicitly checks the Gentoo |
14 |
> >>> keyserver |
15 |
> >>> pool with a much higher frequency" strongly implies that we check |
16 |
> >>> the |
17 |
> >>> non-Gentoo pools with a non-zero frequency. |
18 |
> >>> |
19 |
> >>> |
20 |
> >> |
21 |
> >> I'm with Michael on this. I've recently experienced this issue myself |
22 |
> >> as the |
23 |
> >> instruction to upload the key to the Gentoo keyserver is separate |
24 |
> >> from the |
25 |
> >> GLEP63[1] document. It doesn't matter that the step is documented if |
26 |
> >> the Holy |
27 |
> >> Tome GLEP63 doesn't mention it. What hint would I have to look for a |
28 |
> >> supplemental document to provide that specific step? |
29 |
> >> |
30 |
> >> According to GLEP 63, uploading to the SKS keyserver is a |
31 |
> >> requirement. |
32 |
> >> However, it fails to specify which SKS keyserver. In fact, neither |
33 |
> >> "SKS" nor |
34 |
> >> "keyserver" are defined in GLEP63. Ergo, the natural interpretation |
35 |
> >> is *anything* |
36 |
> >> that's called an SKS keyserver will satisfy the requirement. As long |
37 |
> >> as the |
38 |
> >> developer can submit the key, the requirement is met. |
39 |
> >> |
40 |
> >> Additionally, the supplemental document[2] doesn't say developers |
41 |
> >> must upload |
42 |
> >> via an internal host, but that devs should upload to both SKS and the |
43 |
> >> Gentoo |
44 |
> >> keyserver. Yes, it says the Gentoo keyserver is currently restricted |
45 |
> >> to syncing |
46 |
> >> with "authorized Gentoo hosts", but that's a nonsense phrase and |
47 |
> >> unhelpful. It |
48 |
> >> assumes I know what the authorized Gentoo hosts are. It doesn't |
49 |
> >> clearly state |
50 |
> >> what they are. It kind of hints that it will pull from SKS |
51 |
> >> eventually, but it |
52 |
> >> could take a long time. |
53 |
> >> |
54 |
> >> I understand we temporarily stopped syncing with the public keyserver |
55 |
> >> out of an |
56 |
> >> overabundance of caution. However, that shouldn't have been done |
57 |
> >> without |
58 |
> >> updating every official Gentoo resource regarding how devs should |
59 |
> >> handle their |
60 |
> >> keys, which as far as I know is only two documents[1,2]. A whopping 2 |
61 |
> >> documents. |
62 |
> >> |
63 |
> >> This new (I know it's been around for a year but that doesn't make it |
64 |
> >> any less |
65 |
> >> new), stricter requirement, should be **explicitly** stated in |
66 |
> >> GLEP63, properly |
67 |
> >> referencing the justification[3], and linking to the infra |
68 |
> >> supplemental |
69 |
> >> document. The infra supplemental document needs to then use the |
70 |
> >> phrase "must" in |
71 |
> >> place of "should" when informing readers to upload to two different |
72 |
> >> locations. |
73 |
> > |
74 |
> > ...and what have you done to resolve the problem, except for making |
75 |
> > oververbose complaints and demands in middle of some random thread? |
76 |
> > |
77 |
> Discuss it, which is more than you have done here. There is no need to |
78 |
> berate signal because you feel like making noise. |
79 |
> |
80 |
> Formulating and discussing ways to fix problems before actually fixing |
81 |
> them helps to reduce effort wasted on rebuilding old solutions which |
82 |
> have failed for whatever reason. In this case documentation needs to be |
83 |
> updated, discussing the appropriate manner in which to update which |
84 |
> documentation seems to be more grounds for engagement than recrimination. |
85 |
> |
86 |
> On the subject of updating the documentation, the proposal seems |
87 |
> generally sound; do you have any constructive criticism of it? |
88 |
> |
89 |
|
90 |
So I can understand where Michał's reaction comes from. On my first |
91 |
read through Aaron's message, it seemed like a long email complaining |
92 |
about things that had been done wrong. Upon re-reading it with a |
93 |
different mindset, it doesn't seem so bad if you skip over some of the |
94 |
text. |
95 |
|
96 |
For example, I don't think the paragraph below is necessary, and could |
97 |
evoke a defensive reaction from the recipient. |
98 |
|
99 |
> I understand we temporarily stopped syncing with the public keyserver out of an |
100 |
> overabundance of caution. However, that shouldn't have been done without |
101 |
> updating every official Gentoo resource regarding how devs should handle their |
102 |
> keys, which as far as I know is only two documents[1,2]. A whopping 2 documents. |
103 |
|
104 |
I think a shorter email simply requesting that the documentation be |
105 |
updated would have sufficed. |