| 1 |
On 2018-06-23 04:57, Marty E. Plummer wrote: |
| 2 |
> On Fri, Jun 22, 2018 at 09:50:50PM -0500, Marty E. Plummer wrote: |
| 3 |
>> So, as you may be aware I've been doing some work on moving bzip2 to an |
| 4 |
>> autotools based build. Recently I've ran into app-crypt/mhash, which is |
| 5 |
>> in a semi-abandoned state (talking with the maintainer on twitter atm), |
| 6 |
>> and I was thinking it may be a good idea to set up a project for keeping |
| 7 |
>> these semi-abandoned and really-abandoned libraries and projects up to |
| 8 |
>> date and such. |
| 9 |
>> |
| 10 |
>> Basically, an upstream for packages who's upstream is either |
| 11 |
>> uncontactable or is otherwise not accepting bug fixes and patches. So |
| 12 |
>> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure |
| 13 |
>> there are others in this state. |
| 14 |
>> |
| 15 |
> Or... call it proxy-upstream, to be in line with the current proxy-maint |
| 16 |
> setup? |
| 17 |
|
| 18 |
Please do not call it proxy-*. |
| 19 |
The invented word proxymaintainer and proxiedmaintainer are not usefull. |
| 20 |
They get always mixed, and are not understood outside of Gentoo. |
| 21 |
assistant developer or trainee developer would have been much more useful. |
| 22 |
|
| 23 |
Beside the naming I like the idea, that you want to take care for all |
| 24 |
abandoned libs. |
| 25 |
|
| 26 |
Please note, that you can not generate more manpower by creating a |
| 27 |
project. In 2015 I calculated |
| 28 |
|
| 29 |
===================================================== |
| 30 |
|
| 31 |
(Number of developers) / (Number of Projects) < 1.4 |
| 32 |
|
| 33 |
===================================================== |
| 34 |
|
| 35 |
Which explains, why most projects today are run by mostly one active person. |
| 36 |
|
| 37 |
If you find an important library, where upstream is dead, fork it and |
| 38 |
take responsibility for it. |
| 39 |
|
| 40 |
It makes no sense to make a pool of dead and important software and |
| 41 |
delegate the responsibility to a team where nobody really knows the |
| 42 |
software. |
| 43 |
|
| 44 |
Better pick a library, communicate with maintainers of the other |
| 45 |
distributions and fork it. Keep the library alive in the fork. |
| 46 |
|
| 47 |
It is important for the security to let dead projects die. |
| 48 |
|
| 49 |
-- |
| 50 |
Best, |
| 51 |
Jonas |
Archives