> On Jun 23, 2018, at 9:05 AM, Jonas Stein <jst...@gentoo.org> wrote:
>
>> On 2018-06-23 04:57, Marty E. Plummer wrote:
>>> On Fri, Jun 22, 2018 at 09:50:50PM -0500, Marty E. Plummer wrote:
>>> So, as you may be aware I've been doing some work on moving bzip2 to an
>>> autotools based build. Recently I've ran into app-crypt/mhash, which is
>>> in a semi-abandoned state (talking with the maintainer on twitter atm),
>>> and I was thinking it may be a good idea to set up a project for keeping
>>> these semi-abandoned and really-abandoned libraries and projects up to
>>> date and such.
>>>
>>> Basically, an upstream for packages who's upstream is either
>>> uncontactable or is otherwise not accepting bug fixes and patches. So
>>> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
>>> there are others in this state.
>>>
>> Or... call it proxy-upstream, to be in line with the current proxy-maint
>> setup?
>
> Please do not call it proxy-*.
> The invented word proxymaintainer and proxiedmaintainer are not usefull.
> They get always mixed, and are not understood outside of Gentoo.
> assistant developer or trainee developer would have been much more useful.
Until we have a better name, why not call it the GPL project? GPL meaning:
Gentoo
POSIX
Libraries
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.
>
> Beside the naming I like the idea, that you want to take care for all
> abandoned libs.
>
> Please note, that you can not generate more manpower by creating a
> project. In 2015 I calculated
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.
>
> =====================================================
>
> (Number of developers) / (Number of Projects) < 1.4
>
> =====================================================
>
> Which explains, why most projects today are run by mostly one active person.
>
> If you find an important library, where upstream is dead, fork it and
> take responsibility for it.
I will call this point 1 of yours.
That sounds like what this project is intended to do.
>
> It makes no sense to make a pool of dead and important software and
> delegate the responsibility to a team where nobody really knows the
> software.
I will call this point 2 of yours.
It depends on the importance of the software.
>
> Better pick a library, communicate with maintainers of the other
> distributions and fork it. Keep the library alive in the fork.
I feel like this is the same as 1.
>
> It is important for the security to let dead projects die.
I feel like this is 2, and that it contradicts 1.
>
> --
> Best,
> Jonas
>
