Re: [gentoo-dev] Idea for a new project: gentoo-libs
On Fri, 22 Jun 2018 21:50:50 -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. It may be worth mentioning that myself and a handful of others are kicking around the idea of creating a "vendorised upstream", which essentially treats all upstreams as unmaintained, and acts as a middle ground between upstream and linux distributions/end users, by re-shipping upstreams code with fixes, in a format similar to upstreams, but with the mentality of a Linux Vendor. Changes to this project would of course be made under the assumption that upstream would one day wake up, and may be interested in adopting some or all of our fixes ( and for upstreams that are currently not actually dead, this may happen sooner than later ) Presently, this is limited in scope to vendorizing CPAN, but it may grow. In concept, this is of course much more work than your idea, but it has a few advantages, particularly with regards to integrating various vendors patches in a single place. But obviously, such a project is somewhat gargantuan, and getting the working concept off the ground is going to take a while :) pgpIFZaaxCeG6.pgp Description: OpenPGP digital signature
[gentoo-dev] Developer commit timeline updates
Hi, everyone. I'd like to just make a short announcement that I've updated the developer commit timeline [1]. Besides the usual periodic update, there are two major changes: a. I've added commit counts to the bars (in the popups shown upon hovering the bar), b. I've created an additional timeline for determining activity of active Gentoo developers, as a partial replacement for the semi-broken 'slacker' script used by Undertakers [2]. Quick rehash for those who don't know the pages: those timelines present the commit activity of current and past Gentoo developers based on gentoo.git (with CVS history grafted). The bars represent adjacent periods of activity, and are interrupted when a developer hadn't committed for a period 3 months. The timeline for historical devs [1] is ordered by the earliest commit, so should roughly represent the order in which developers joined. Note that in case of developers who used to be proxied maintainers, the earlier p-m commits are also counted if their respective e-mail matches. The timeline for active devs [2] is order by the latest commit, so should roughly start with developers who are inactive the longest. It only lists developers who have commit access to gentoo.git. [1]:https://dev.gentoo.org/~mgorny/dev-timeline.html [2]:https://dev.gentoo.org/~mgorny/active-devs.html -- Best regards, Michał Górny
Re: [gentoo-dev] Idea for a new project: gentoo-libs
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. 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 = (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. 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. Better pick a library, communicate with maintainers of the other distributions and fork it. Keep the library alive in the fork. It is important for the security to let dead projects die. -- Best, Jonas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Idea for a new project: gentoo-libs
On 2018.06.23 09:55, Marty E. Plummer wrote: > On Sat, Jun 23, 2018 at 10:15:06AM +0200, Paweł Hajdan, Jr. wrote: > > On 23/06/2018 09:43, Mikle Kolyada wrote: > > > But how would it serve gentoo itself? Lots of packages in the > distro > > > have dead upstream but still work. > > > Why would you want to make gentoo an upstream area rather than > moving a > > > dead project itself, say, > > > to github and do the job there? > > > > +1 > > > > I like the idea of taking responsibility for the abandoned packages > that > > are still useful. > > > > It's probably not Gentoo-specific, so a distro-neutral way of > handling > > that seems most appropriate. > > > > It may even be worth it to coordinate with other distros (and maybe > > downstreams) so that the new version becomes a standard. > > > > Finally, having more than one person on this (to help continuity), > and a > > common platform like GitHub also seem very helpful. > > > > Paweł > > > Agreed in general; the problem is getting it started at all; difficult > to get other distros to join if there is nothing to join. > > > A couple of generalisations. The first solution to unmaintained packages should be to move to an alternative, if that's possible. Gentoo does not have the resource to be upstream for very much for the entire Linux community, a point already made by others. In volunteer groups things get done by those who want to do them. Others join later. I think the quote I'm looking for is "Build it and they will come". -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpVfuXnGRrnH.pgp Description: PGP signature
Re: [gentoo-dev] Idea for a new project: gentoo-libs
On Sat, Jun 23, 2018 at 3:30 AM, Marty E. Plummer wrote: > On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote: > > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E. > > Plummer napisał: > > > 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. > > > > > > > So in order to fix problem of semi-abandoned packages, you're creating > > an indirect herd-like entity that will soon be semi-abandoned itself > > because people will be dumping random packages into it and afterwards > > nobody will claim responsibility for them. > > > > -- > > Best regards, > > Michał Górny > > No, I mean for packages which are important enough in gentoo to warrant > such treatment. For instance, every email I've tried for bzip2's > upstream bounced or recieved no reply. That, I assume, is important > enough to actually maintain and improve. Any other library which may be > as important which are as inactive would be added. > > I suspect this might be better done in the Linux foundation itself as they have staffing for core components that everyone is using. -A
Re: [gentoo-dev] Idea for a new project: gentoo-libs
On Sat, Jun 23, 2018 at 10:15:06AM +0200, Paweł Hajdan, Jr. wrote: > On 23/06/2018 09:43, Mikle Kolyada wrote: > > But how would it serve gentoo itself? Lots of packages in the distro > > have dead upstream but still work. > > Why would you want to make gentoo an upstream area rather than moving a > > dead project itself, say, > > to github and do the job there? > > +1 > > I like the idea of taking responsibility for the abandoned packages that > are still useful. > > It's probably not Gentoo-specific, so a distro-neutral way of handling > that seems most appropriate. > > It may even be worth it to coordinate with other distros (and maybe > downstreams) so that the new version becomes a standard. > > Finally, having more than one person on this (to help continuity), and a > common platform like GitHub also seem very helpful. > > Paweł > Agreed in general; the problem is getting it started at all; difficult to get other distros to join if there is nothing to join.
Re: [gentoo-dev] Idea for a new project: gentoo-libs
On 23/06/2018 09:43, Mikle Kolyada wrote: > But how would it serve gentoo itself? Lots of packages in the distro > have dead upstream but still work. > Why would you want to make gentoo an upstream area rather than moving a > dead project itself, say, > to github and do the job there? +1 I like the idea of taking responsibility for the abandoned packages that are still useful. It's probably not Gentoo-specific, so a distro-neutral way of handling that seems most appropriate. It may even be worth it to coordinate with other distros (and maybe downstreams) so that the new version becomes a standard. Finally, having more than one person on this (to help continuity), and a common platform like GitHub also seem very helpful. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Idea for a new project: gentoo-libs
On 23.06.2018 05:50, 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. But how would it serve gentoo itself? Lots of packages in the distro have dead upstream but still work. Why would you want to make gentoo an upstream area rather than moving a dead project itself, say, to github and do the job there? > > 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. > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Idea for a new project: gentoo-libs
W dniu sob, 23.06.2018 o godzinie 02∶30 -0500, użytkownik Marty E. Plummer napisał: > On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote: > > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E. > > Plummer napisał: > > > 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. > > > > > > > So in order to fix problem of semi-abandoned packages, you're creating > > an indirect herd-like entity that will soon be semi-abandoned itself > > because people will be dumping random packages into it and afterwards > > nobody will claim responsibility for them. > > > > -- > > Best regards, > > Michał Górny > > No, I mean for packages which are important enough in gentoo to warrant > such treatment. For instance, every email I've tried for bzip2's > upstream bounced or recieved no reply. That, I assume, is important > enough to actually maintain and improve. Any other library which may be > as important which are as inactive would be added. Sounds like you're going to take over half of base-system ;-). I really prefer having single dedicated individuals for that kind of stuff. Projects just blur the responsibility. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Idea for a new project: gentoo-libs
On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote: > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E. > Plummer napisał: > > 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. > > > > So in order to fix problem of semi-abandoned packages, you're creating > an indirect herd-like entity that will soon be semi-abandoned itself > because people will be dumping random packages into it and afterwards > nobody will claim responsibility for them. > > -- > Best regards, > Michał Górny No, I mean for packages which are important enough in gentoo to warrant such treatment. For instance, every email I've tried for bzip2's upstream bounced or recieved no reply. That, I assume, is important enough to actually maintain and improve. Any other library which may be as important which are as inactive would be added.
Re: [gentoo-dev] Idea for a new project: gentoo-libs
W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E. Plummer napisał: > 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. > So in order to fix problem of semi-abandoned packages, you're creating an indirect herd-like entity that will soon be semi-abandoned itself because people will be dumping random packages into it and afterwards nobody will claim responsibility for them. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/python-axolotl/
Hanno,
W dniu pią, 22.06.2018 o godzinie 17∶39 +, użytkownik Hanno Boeck
napisał:
> commit: acdbda5cb244963b4b7982d96d0538760a385a4d
> Author: Hanno gentoo org>
> AuthorDate: Fri Jun 22 17:39:08 2018 +
> Commit: Hanno Boeck gentoo org>
> CommitDate: Fri Jun 22 17:39:08 2018 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=acdbda5c
>
> dev-python/python-axolotl: Initial commit.
>
> Python support for the Axolotl protocol (used by OMEMO).
>
> Closes: https://bugs.gentoo.org/608882
> Closes: https://github.com/gentoo/gentoo/pull/7778
> Package-Manager: Portage-2.3.40, Repoman-2.3.9
>
> dev-python/python-axolotl/Manifest | 1 +
> dev-python/python-axolotl/metadata.xml | 11 +++
> .../python-axolotl/python-axolotl-0.1.42.ebuild| 23
> ++
> 3 files changed, 35 insertions(+)
>
>
> [...]
> +DEPEND="dev-python/python-axolotl-curve25519[${PYTHON_USEDEP}]
> + dev-python/cryptography[${PYTHON_USEDEP}]
> + dev-python/protobuf-python[${PYTHON_USEDEP}]
> + dev-python/setuptools[${PYTHON_USEDEP}]"
While I really appreciate the willingness to help proxy-maint with
the lot of work we have, I'd really appreciate if you tried to be more
careful about what you're doing and respectful to the team policies.
I have to point out that:
1. You're not on the team or the alias, so that's basically a 'dump off'
commit that we will have to fix for you.
2. You've merged a pull request that was still during review by me,
8 hours after I have *requested changes* and without giving me a chance
to verify that the changes has been made.
3. You've merged an *old version* of the pull request rather than
the newest commits...
4. ...and effectively, you've merged ebuild with a lot of mistakes
and disregarded proxied maintainer's work to fix them; which also means
you didn't properly review/test what you were merging.
So while help is appreciated, please learn how proxy-maint operates
and double-check what you are doing. I have reverted both commits.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
