1 |
On June 26, 2020 11:08:35 AM EDT, Rich Freeman <rich0@g.o> wrote: |
2 |
>On Fri, Jun 26, 2020 at 10:36 AM Aaron Bauman <bman@g.o> wrote: |
3 |
>> |
4 |
>> On June 26, 2020 7:13:07 AM EDT, Rich Freeman <rich0@g.o> |
5 |
>wrote: |
6 |
>> >> Of all the methods listed in the previous posts, the QA reports, |
7 |
>etc. |
8 |
>> >> there is no excuse individuals can't find out if their package is |
9 |
>py2 |
10 |
>> >> only. |
11 |
>> > |
12 |
>> >None of those methods were posted until a day or two ago, and the |
13 |
>> >python team has done nothing to actually ensure all the impacted |
14 |
>> >maintainers are aware of them. Perhaps a communication to |
15 |
>> >-dev-announce with the preferred approach would be better? |
16 |
>> > |
17 |
>> |
18 |
>> You should also look at qa-reports. Do we really need to *teach* |
19 |
>others "how to fish" here? Why can't folks just ask for assistance? |
20 |
> |
21 |
>Just looked at it: |
22 |
> |
23 |
>1. I had no idea that a list of py2-only packages was listed there. |
24 |
>I don't think I've ever actually looked at that page. |
25 |
> |
26 |
|
27 |
Perfect, so you have just shown that you either didn't see the ML posts about QA tools, didn't care to ask other devs what tools are available etc. |
28 |
|
29 |
If history serves me right, qa-reports has existed for many years (of which I have used it) and mgorny often let's folks know about changes to it (e.g. pkgcore). |
30 |
|
31 |
So, thanks for proving my point that all the tooling changes, notices, ML posts, etc don't matter. Someone *will* find something to complain about. |
32 |
|
33 |
|
34 |
>2. The report does not list maintainers, which means nobody is likely |
35 |
>to know they have a package on the list. |
36 |
> |
37 |
|
38 |
Do you argue just to argue? Sad. If someone like Robin (who at one point had like 5% of the tree under his maintainer ship) complained about that I may see it worthwhile. |
39 |
|
40 |
Just another red herring... |
41 |
|
42 |
>> |
43 |
>> See above. Qa-reports will output a very nice list (even a graphic!) |
44 |
>of such things. Anyway, yes, I do expect devs to understand their |
45 |
>packages state if they maintain it. Don't be so myopic. |
46 |
> |
47 |
>Well, you can expect whatever you want, and then you can be frustrated |
48 |
>out of your mind when 95% of devs fail to meet your expectations. |
49 |
> |
50 |
|
51 |
I am not frustrated. I will continue to perform the same in intervals to drive the removal of Py2. |
52 |
|
53 |
>Or you could just work with them where they're at and maybe get your |
54 |
>project completed more quickly and with less effort... |
55 |
> |
56 |
|
57 |
::yawn:: see above remarks showing how folks will find a way to complain. |
58 |
|
59 |
>If you want people to look at a qa-report, maybe post on -dev-announce |
60 |
>and ask everybody to do it? Most people aren't going to be following |
61 |
>all the tools used by the python team if they aren't python devs. |
62 |
> |
63 |
>> >At least some devs here seemed surprised about the masks. Did you |
64 |
>try |
65 |
>> >filing a bug? |
66 |
>> |
67 |
>> Have you looked for said bugs? |
68 |
> |
69 |
>Of course. Do you think I'd invite such an obvious reply without |
70 |
>actually checking. |
71 |
> |
72 |
>I just went to the first complaint on this list about there not being |
73 |
>a bug, and verified that there wasn't a bug. |
74 |
> |
75 |
>As far as I can tell there is no bug for app-misc/golly. If I missed |
76 |
>one feel free to cite it. |
77 |
> |
78 |
>> |
79 |
>> > |
80 |
>> >Masking something for all users is basically like torturing a kitten |
81 |
>> >to get the attention of its owner. It is a necessary step if the |
82 |
>> >package is actually to be removed. I don't think it is even |
83 |
>allowable |
84 |
>> >under our policies if no bug was filed. |
85 |
>> > |
86 |
>> |
87 |
>> Do tell where said policy is? |
88 |
> |
89 |
>https://devmanual.gentoo.org/general-concepts/package-maintainers/index.html |
90 |
> |
91 |
>Granted, a mask isn't a package commit, but I think the spirit of the |
92 |
>policy covers it. |
93 |
> |
94 |
>In any case, there is no reason not to communicate with a maintainer |
95 |
>before touching a package. That should involve something more than a |
96 |
>generic notice that everybody should become a detective to figure out |
97 |
>if they are covered by an upcoming change. If you have a list of |
98 |
>impacted packages, then just file bugs against them. |
99 |
> |
100 |
>> |
101 |
>> Nothing is really hard about masking packages for removal... |
102 |
>honestly. |
103 |
> |
104 |
>The complaint isn't that masks are hard on you. The complaint is that |
105 |
>it bombards users with unnecessary warnings. |
106 |
> |
107 |
|
108 |
Sadly, many users have contributed more than some devs to fix packages. I often get emails directly from users wanting to fix things. I will start forwarding them to you. |
109 |
|
110 |
>> The work comes in defending the position here for the few that |
111 |
>complain. |
112 |
> |
113 |
>And how are you enjoying doing all that extra work? Would you prefer |
114 |
>if devs started opening up QA/Comrel bugs that you then have to |
115 |
>formally respond to? |
116 |
> |
117 |
|
118 |
There is one open now. Seems QA hasn't spoken up yet... |
119 |
|
120 |
>Or maybe you could try notifying devs before masking their packages? |
121 |
> |
122 |
>> If I filed a bug... they would complain or not respond... If I sent |
123 |
>out a dev-announce they would complain or not respond. |
124 |
> |
125 |
>Sometimes, sure. But at least you would have gone through due |
126 |
>process, and you're unlikely to get much push back. |
127 |
> |
128 |
>And I suspect a number of those packages would actually get fixed. |
129 |
> |
130 |
>> |
131 |
>> You see the fun here? Which method is effective? Mask a 100 packages |
132 |
>for removal... Someone complains... A few packages get saved and 90 get |
133 |
>removed... Life goes on. |
134 |
> |
135 |
>Would you want a dev to just mask one of your packages if they saw a |
136 |
>bug in it, without bothering to open a bug? |
137 |
|
138 |
Depends on the type of bug. Security RCE? Sure. Deprecated code/EOL interpreter? Sure. |
139 |
|
140 |
-- |
141 |
Sent from my Android device with K-9 Mail. Please excuse my brevity. |