1 |
> On Jun 23, 2018, at 9:05 AM, Jonas Stein <jstein@g.o> wrote: |
2 |
> |
3 |
>> On 2018-06-23 04:57, Marty E. Plummer wrote: |
4 |
>>> On Fri, Jun 22, 2018 at 09:50:50PM -0500, Marty E. Plummer wrote: |
5 |
>>> So, as you may be aware I've been doing some work on moving bzip2 to an |
6 |
>>> autotools based build. Recently I've ran into app-crypt/mhash, which is |
7 |
>>> in a semi-abandoned state (talking with the maintainer on twitter atm), |
8 |
>>> and I was thinking it may be a good idea to set up a project for keeping |
9 |
>>> these semi-abandoned and really-abandoned libraries and projects up to |
10 |
>>> date and such. |
11 |
>>> |
12 |
>>> Basically, an upstream for packages who's upstream is either |
13 |
>>> uncontactable or is otherwise not accepting bug fixes and patches. So |
14 |
>>> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure |
15 |
>>> there are others in this state. |
16 |
>>> |
17 |
>> Or... call it proxy-upstream, to be in line with the current proxy-maint |
18 |
>> setup? |
19 |
> |
20 |
> Please do not call it proxy-*. |
21 |
> The invented word proxymaintainer and proxiedmaintainer are not usefull. |
22 |
> They get always mixed, and are not understood outside of Gentoo. |
23 |
> assistant developer or trainee developer would have been much more useful. |
24 |
|
25 |
Until we have a better name, why not call it the GPL project? GPL meaning: |
26 |
|
27 |
Gentoo |
28 |
POSIX |
29 |
Libraries |
30 |
|
31 |
Misunderstandings from the obvious acronym collision aside, I think the name GPL Project would be more appealing to outsiders than “proxy-libs”, which I agree would be misunderstood in the worst possible ways. |
32 |
> |
33 |
> Beside the naming I like the idea, that you want to take care for all |
34 |
> abandoned libs. |
35 |
> |
36 |
> Please note, that you can not generate more manpower by creating a |
37 |
> project. In 2015 I calculated |
38 |
In the case of creating a new upstream for key libraries shared by distributions, I disagree. As long as other distribution maintainers get on board, the deduplication of effort will result in more man power. |
39 |
> |
40 |
> ===================================================== |
41 |
> |
42 |
> (Number of developers) / (Number of Projects) < 1.4 |
43 |
> |
44 |
> ===================================================== |
45 |
> |
46 |
> Which explains, why most projects today are run by mostly one active person. |
47 |
> |
48 |
> If you find an important library, where upstream is dead, fork it and |
49 |
> take responsibility for it. |
50 |
I will call this point 1 of yours. |
51 |
|
52 |
That sounds like what this project is intended to do. |
53 |
> |
54 |
> It makes no sense to make a pool of dead and important software and |
55 |
> delegate the responsibility to a team where nobody really knows the |
56 |
> software. |
57 |
I will call this point 2 of yours. |
58 |
|
59 |
It depends on the importance of the software. |
60 |
> |
61 |
> Better pick a library, communicate with maintainers of the other |
62 |
> distributions and fork it. Keep the library alive in the fork. |
63 |
I feel like this is the same as 1. |
64 |
> |
65 |
> It is important for the security to let dead projects die. |
66 |
I feel like this is 2, and that it contradicts 1. |
67 |
> |
68 |
> -- |
69 |
> Best, |
70 |
> Jonas |
71 |
> |