1 |
On 02/12/2016 08:48 AM, Michał Górny wrote: |
2 |
> Dear Ignorant Patrick, |
3 |
Hello human! Your politeness module seems to have crashed. |
4 |
|
5 |
And thanks for making me do a quintuple facepalm with backflip. I think |
6 |
that's a new record. So anyway ... |
7 |
> On Thu, 11 Feb 2016 21:15:34 +0100 |
8 |
> Patrick Lauer <patrick@g.o> wrote: |
9 |
> |
10 |
>> ... or why just changing stuff is not enough: |
11 |
>> |
12 |
>> A few days ago I was told that |
13 |
>> http://euscan.gentooexperimental.org/herds/ was displaying an empty |
14 |
>> list. Which is annoying because people sometimes want to see what |
15 |
>> upstream updates are available for their herd. |
16 |
>> |
17 |
>> Well, we renamed herd to project. Because reasons. |
18 |
> No, we didn't. Herd was collection a packages. Project is a collection |
19 |
> of developers. Project coexisted with herds for a long time. As it was |
20 |
> explained already in length. Multiple times. |
21 |
So you just pivoted the organization from A->B to B->A. |
22 |
|
23 |
I still don't see the advantage in that. Maybe I should have expressed |
24 |
my concerns more vocally, but in general I don't have time to worry |
25 |
about all the little things. |
26 |
|
27 |
> |
28 |
>> I don't care how it is named, but this change broke euscan in a |
29 |
>> user-visible way. Now I could just try to rename things there too, but |
30 |
>> that won't work: |
31 |
>> |
32 |
>> euscan uses gentoolkit for parsing metadata.xml and herds.xml |
33 |
>> (Since herds.xml is basically unmaintained cruft at this point this will |
34 |
>> break soon anyway ... but ...) |
35 |
>> Changing gentoolkit to use projects.xml instead of herds.xml won't be a |
36 |
>> simple migration since the data organization changed. |
37 |
>> |
38 |
>> Now instead of looking up [metadata.xml] -> (herd name) -> [herds.xml] |
39 |
>> -> email it goes backwards: |
40 |
>> [metadata.xml] -> (maintainer type=project) -> email -> [projects.xml] |
41 |
>> -> Project name |
42 |
>> |
43 |
>> Since this involves XML and python's ElementTree library it's a |
44 |
>> nontrivial change that also removes a few now useless helpers |
45 |
>> (_get_herd_email has no reason to be, but we'd need a _get_herd_name |
46 |
>> helper instead. Err, get_proj ... ah well, whatever name works) |
47 |
>> |
48 |
>> And all that just so (1) gentoolkit output works and (2) euscan updates |
49 |
>> properly. Both of which I don't really care about much, but now that |
50 |
>> I've invested ~4h into debugging and trying to fix it I'm a tiny bit |
51 |
>> IRRITATED. |
52 |
> You are completely incorrect, as you have been told already multiple |
53 |
> times. People would really appreciate if you spent at least a little |
54 |
> part of the time you spend complaining, inventing issues and insulting |
55 |
> others listening to what they're telling you. |
56 |
> |
57 |
> So let me repeat, again. euscan works. Want packages from Python |
58 |
> project? Then select the appropriate maintainer from the 'maintainers' |
59 |
> section: |
60 |
So you're saying I have no way to search by herd, err, project now. |
61 |
And I can't even find projects in the soup of maintainers. |
62 |
|
63 |
... and metadata is now partially broken. |
64 |
|
65 |
*ahem* This not of good idea sounding. |
66 |
> |
67 |
> http://euscan.gentooexperimental.org/maintainers/python@g.o/ |
68 |
> |
69 |
> Done. Was it that hard? Now the big surprise: you didn't have to create |
70 |
> some convoluted logic to get that! You don't need projects.xml to get |
71 |
> that! Of course, you'd know that if you would listen for a single |
72 |
> minute instead of throwing insults at others. |
73 |
If you had actually understood my criticism you would understand why I |
74 |
might be a tiny bit irritated. |
75 |
|
76 |
Some functionality is now actively *gone*, and that's not a feature. |
77 |
> |
78 |
>> Please, next time someone has the brilliant idea of changing stuff just |
79 |
>> to change it (I still don't see a reason why we had to change |
80 |
>> metadata.xml?), it should be required that support tools are fixed |
81 |
>> *before* the change, and working versions released. This avoids grumpy |
82 |
>> people and makes it harder for those that change things to head-in-sand |
83 |
>> and claim everything works as expected when it obviously doesn't. |
84 |
> The fact is: things *work as expected*. If you have problem accepting |
85 |
> reality as it is, then it's your fault, not ours. Herds no longer |
86 |
> exist. Everything is based on *maintainers* now. Tools are not supposed |
87 |
> to magically turn project information back into herd-oriented design. |
88 |
Right, so gentoolkit returning bad info is a good thing. I find that |
89 |
hard to integrate into my understanding of the world ... |
90 |
|
91 |
|
92 |
Please don't redefine what 'expected' means to suit your limited |
93 |
usecases. It just causes friction and unhappy response from people that |
94 |
now have to spend lots of time figuring out how things diverge from |
95 |
their 'expected', which usually ends in *facepalm* omg how did that happen. |
96 |
|
97 |
Plus the usual sequence of strongly-worded letters to the UN ;) |
98 |
> |
99 |
> As I said before, please direct any further complaints directly to |
100 |
> the Council, and stop insulting the messenger. The Council has banned |
101 |
> herds explicitly before I even started working on GLEP 67. It was |
102 |
> the guideline I had to follow. |
103 |
> |
104 |
Hey thanks for publically demonstrating your unwillingness to cooperate |
105 |
with others. |
106 |
|
107 |
So now I know that in the future I will |
108 |
|
109 |
(1) categorically deny any change requests coming from you and |
110 |
(2) block/revert any changes that I don't like or understand. |
111 |
|
112 |
Nothing personal, just basic sanity. |
113 |
|
114 |
|
115 |
Have fun not being a team player, |
116 |
|
117 |
Patrick |