From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 81F40138334 for ; Sun, 5 Aug 2018 16:55:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EC400E07A9; Sun, 5 Aug 2018 16:55:32 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 790F4E079C for ; Sun, 5 Aug 2018 16:55:32 +0000 (UTC) Received: from [192.168.5.121] (pool-96-232-204-110.nycmny.fios.verizon.net [96.232.204.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id CB6AD335C94 for ; Sun, 5 Aug 2018 16:55:24 +0000 (UTC) From: Richard Yao Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 (1.0) Date: Sun, 5 Aug 2018 12:55:19 -0400 Subject: Re: [gentoo-dev] Idea for a new project: gentoo-libs Message-Id: References: <20180623025046.djmsv44moxuqkv6t@proprietary-killer> <20180623025739.clijycvxkfskmmdy@proprietary-killer> In-Reply-To: To: gentoo-dev@lists.gentoo.org X-Mailer: iPad Mail (15G77) X-Archives-Salt: 7bf7b02a-fd17-4094-8a78-f49b1fd589d2 X-Archives-Hash: f0fae8a6c749881bf9f713202f37636f > On Jun 23, 2018, at 9:05 AM, Jonas Stein wrote: >=20 >> 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. >>>=20 >>> 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. >>>=20 >> Or... call it proxy-upstream, to be in line with the current proxy-maint >> setup? >=20 > 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 =E2=80=9Cproxy-libs=E2= =80=9D, which I agree would be misunderstood in the worst possible ways. >=20 > Beside the naming I like the idea, that you want to take care for all > abandoned libs. >=20 > 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 distribut= ions, I disagree. As long as other distribution maintainers get on board, th= e deduplication of effort will result in more man power. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >=20 > (Number of developers) / (Number of Projects) < 1.4 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >=20 > Which explains, why most projects today are run by mostly one active perso= n. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > It is important for the security to let dead projects die. I feel like this is 2, and that it contradicts 1. >=20 > --=20 > Best, > Jonas >=20