1 |
On 2020-06-20 21:24, Aaron Bauman wrote: |
2 |
> Thomas, unfortunately, I am shocked at your choice of words here. I |
3 |
> think it is reasonable that any developer would understand a lack |
4 |
> of forward momentum in removing Py2 only packages only drives |
5 |
> stagnation. |
6 |
> |
7 |
> If you have a more effective method to doing so, I am open to |
8 |
> suggestions. |
9 |
|
10 |
Like I am shocked about your recent actions: |
11 |
|
12 |
Remember what you did in January. I thought it became clear that next |
13 |
time you will share your list before just masking stuff to avoid things |
14 |
which happened then. |
15 |
|
16 |
In the beginning of this month you just decided to disband graphics |
17 |
project. On your own. Please tell me what gave you the authority to just |
18 |
do that? You didn't even share your plan before executing it on any |
19 |
mailing list. Something that should be common sense, if not even necessary. |
20 |
The whole action was so destructive that you couldn't evenb just undo it |
21 |
because you also deleted stuff on Wiki. |
22 |
|
23 |
And now you did it again with Py2-only packages. |
24 |
|
25 |
And again for no good reason. |
26 |
|
27 |
Like multiple people have already shown you, many packages from that |
28 |
list are not even blocking Py3 transition. |
29 |
|
30 |
Let me tell you what a mask will cause: |
31 |
A mask is destructive and requires user interaction. Therefore a mask |
32 |
isn't something to play with, "Oh, let's test if someone will |
33 |
complain... it's just a mask, we can just unmask in case...". |
34 |
|
35 |
No, imagine there are people out there using Gentoo in production and |
36 |
not as playground. These people maybe have automated build systems which |
37 |
are creating systems/images (do you know Dockers for example?). Whenever |
38 |
you mask something and that package is referenced in configuration, you |
39 |
will break that build. |
40 |
|
41 |
That's not funny if this is happening for no real reason. |
42 |
|
43 |
|
44 |
> re: net-mail/offlineimap... there are alternatives. |
45 |
|
46 |
I think you don't really know that tool. It's an industry standard. |
47 |
Sure, there are already successors (however, not in Gentoo). But the |
48 |
package itself is still working and actively maintained and when you |
49 |
will use it in production you usually have extended/adjusted the tool |
50 |
for your environment using the plugin system the tool provides. That's |
51 |
not something you will be able to replace with something new in 5 minutes. |
52 |
|
53 |
And I repeat myself: Especially not when there is no need to do that |
54 |
because because the package itself is working fine and there is absolute |
55 |
no reason to get rid of it. |
56 |
|
57 |
Last but not least: Gentoo is about choices. It's not your job to decide |
58 |
what people should use. Sure, if you maintained a package and will stop |
59 |
using it so it will become maintainer-needed and masked for removal at |
60 |
some point because it's outdated, vulnerable and/or not working anymore, |
61 |
that's OK. But if someone else will pick up this package... and |
62 |
offlineimap in Gentoo is working and up-to-date. |
63 |
|
64 |
Heck, we could even talk about how rude it is to force a maintainer to |
65 |
drop its package. And yes, even p-m should be treated like real devs. So |
66 |
you can't just kill their packages because you want to. |
67 |
|
68 |
|
69 |
-- |
70 |
Regards, |
71 |
Thomas Deutschmann / Gentoo Linux Developer |
72 |
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 |