1 |
On Sun, Jun 7, 2020 at 7:22 PM Philip Webb <purslow@××××××××.net> wrote: |
2 |
> |
3 |
> 200607 Pacho Ramos wrote: |
4 |
> > I think this is the list of completely unmaintained packages now, |
5 |
> > indeed most of them, around 100. |
6 |
> |
7 |
> -- extract from list -- |
8 |
> |
9 |
> > media-gfx/imagemagick : 200516 |
10 |
> > media-libs/giflib : 200312 |
11 |
> > media-libs/libjpeg-turbo : 200328 |
12 |
> > media-libs/openjpeg : 200328 |
13 |
> > virtual/jpeg : 200606 |
14 |
> |
15 |
> There have been upgrades of all these in recent months : |
16 |
> dates when I upgraded on my desktop system are added (the last yesterday). |
17 |
> Surely, that means someone is maintaining them. |
18 |
> Perhaps the culprits could own up (smile). |
19 |
> |
20 |
> As a long-time user, I find it disturbing |
21 |
> that a huge list of packages should suddenly be declared unmaintained, |
22 |
> esp as some of them -- eg above -- are likely needed by most users. |
23 |
|
24 |
They were not maintained by identified developers before - that is the |
25 |
point. The only thing that is changing is that metadata is being |
26 |
updated to reflect reality. Now these packages will get more notice |
27 |
and developers can set up and maintain them as needed. |
28 |
|
29 |
The packages aren't being removed - just the project. |
30 |
|
31 |
If any of the packages assigned to the graphics projects already had |
32 |
individual maintainers then those would still remain after the project |
33 |
is removed. |
34 |
|
35 |
Put it this way - suppose we created a project called "dummy" with no |
36 |
developers in it, and we assigned that project to all the packages |
37 |
that are maintaner-needed. Would that actually change anything? XML |
38 |
tags in metadata files don't maintain packages - people do. |
39 |
|
40 |
This sort of thing has happened many times in the past. Sometimes it |
41 |
does result in packages getting treecleaned, but mainly when they have |
42 |
other serious issues. Popular packages aren't likely to get removed |
43 |
this way - certainly not something like libjpeg or imagemagick and so |
44 |
on. |
45 |
|
46 |
-- |
47 |
Rich |