Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Richard Yao]

> On Jun 23, 2018, at 6:59 AM, Alec Warner  wrote:
> 
> 
> 
>> 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.
This would put decision making power into the hands of bureaucrats. I would 
rather it remain in a community of volunteers.

I consider upstream development efforts by Gentoo developers to be beneficial 
to Gentoo. Nothing makes fixing an issue in Gentoo at upstream a priority quite 
like it affecting a key upstream developer in his day to day life.

Also, the Linux Foundation is not embarking on such a project and we clearly 
have someone willing to try, so I say that we should go for it. Having people 
that wish to take a more active role in upstream development would not make us 
any worse off. It is their time to volunteer, so it is not like they will 
volunteer it for something else if we discourage them.
> 
> -A
> 
> 
> 

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Richard Yao]

> On Jun 23, 2018, at 9:05 AM, Jonas Stein  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
> 

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Alec Warner]

On Sun, Aug 5, 2018 at 12:45 PM, Richard Yao  wrote:

>
>
> On Jun 23, 2018, at 6:59 AM, Alec Warner  wrote:
>
>
>
> 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.
>
> This would put decision making power into the hands of bureaucrats. I
> would rather it remain in a community of volunteers.
>

Meh, it doesn't hurt to ask there about interest (they certainly fund
development of other components.) Its not like they have to accept, or that
declining somehow inhibits this development.

Part of my frustration is that seemingly "anything open source related can
be held in Gentoo" and I'm somewhat against that as I feel it dilutes the
Gentoo mission. We are here to make a distribution, not maintain random
libraries. If you want to do that feel free; but I don't see a need for
that work to be associated with Gentoo.


>
> I consider upstream development efforts by Gentoo developers to be
> beneficial to Gentoo. Nothing makes fixing an issue in Gentoo at upstream a
> priority quite like it affecting a key upstream developer in his day to day
> life.
>

>
> Also, the Linux Foundation is not embarking on such a project and we
> clearly have someone willing to try, so I say that we should go for it.
> Having people that wish to take a more active role in upstream development
> would not make us any worse off. It is their time to volunteer, so it is
> not like they will volunteer it for something else if we discourage them.
>

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[M. J. Everitt]

On 05/08/18 18:01, Alec Warner wrote [excerpted]:
>
>
> On Sun, Aug 5, 2018 at 12:45 PM, Richard Yao  > wrote:
>
>
>
> On Jun 23, 2018, at 6:59 AM, Alec Warner  > wrote:
>
>>
>> I suspect this might be better done in the Linux foundation
>> itself as they have staffing for core components that everyone is
>> using.
> This would put decision making power into the hands of
> bureaucrats. I would rather it remain in a community of volunteers.
>
>
> Meh, it doesn't hurt to ask there about interest (they certainly fund
> development of other components.) Its not like they have to accept, or
> that declining somehow inhibits this development.
>
> Part of my frustration is that seemingly "anything open source related
> can be held in Gentoo" and I'm somewhat against that as I feel it
> dilutes the Gentoo mission. We are here to make a distribution, not
> maintain random libraries. If you want to do that feel free; but I
> don't see a need for that work to be associated with Gentoo.
>  
Maintaining a distro is increasingly becoming more a case of fixing
upstream's shortcomings, as they move towards completely-bundled
packages instead of thorough testing. Creating distribution packages,
especially in a source-based distro like Gentoo, requires quite a lot of
testing, and a lot of collating user feedback (in terms of bugs) to make
sure that the packages built do actually *work*.

So no, whilst it does seem on the surface to be a dilution of effort, if
it reduces the overall effort to generate robust packages, and
distributes it across multiple distros and developers, whilst
co-ordination and communication may prove a new challenge, I think this
is complementary to what everyone is trying to achieve.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Rich Freeman]

On Sun, Aug 5, 2018 at 1:01 PM Alec Warner  wrote:
>
>
> Part of my frustration is that seemingly "anything open source related
> can be held in Gentoo" and I'm somewhat against that as I feel it
> dilutes the Gentoo mission. We are here to make a distribution, not
> maintain random libraries. If you want to do that feel free; but I
> don't see a need for that work to be associated with Gentoo.
>

Honestly, other than maybe some prestige I don't really get the point
of hosting random software in Gentoo either.  These days getting a
repo on github or any of its 47 competitors is a few clicks.  You have
zero overhead from a governance standpoint, and a dev can of course
stick ebuilds in the main repository with zero interference.  It seems
a lot cleaner from a copyright/etc standpoint as well.

Even openrc is hosted outside of Gentoo these days, which makes perfect sense.

With the distro as a whole it is a bit more complex, though honestly
I'd love to see us get to a point where the whole thing can be
SECURELY hosted entirely off-infra as well, even if we still chose to
run our own infra.  I just see it as a way to both provide options to
our users and ourselves.  For the latter, being able to host anything
on an outside service means that if some component of infra goes down
we could have mirrors already running and pulling from infra, or if
for some reason somebody sues us or roots us or whatever we can pick
up and move without much fuss.

Running your own wiki/bugzilla/lists/etc was about the only way to do
things in the 90s/etc, but these days there are other options...

-- 
Rich

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[M. J. Everitt]

On 05/08/18 18:24, Rich Freeman wrote:
> On Sun, Aug 5, 2018 at 1:01 PM Alec Warner  wrote:
>>
>> Part of my frustration is that seemingly "anything open source related
>> can be held in Gentoo" and I'm somewhat against that as I feel it
>> dilutes the Gentoo mission. We are here to make a distribution, not
>> maintain random libraries. If you want to do that feel free; but I
>> don't see a need for that work to be associated with Gentoo.
>>
> Honestly, other than maybe some prestige I don't really get the point
> of hosting random software in Gentoo either.  These days getting a
> repo on github or any of its 47 competitors is a few clicks.  You have
> zero overhead from a governance standpoint, and a dev can of course
> stick ebuilds in the main repository with zero interference.  It seems
> a lot cleaner from a copyright/etc standpoint as well.
>
> Even openrc is hosted outside of Gentoo these days, which makes perfect sense.
>
> With the distro as a whole it is a bit more complex, though honestly
> I'd love to see us get to a point where the whole thing can be
> SECURELY hosted entirely off-infra as well, even if we still chose to
> run our own infra.  I just see it as a way to both provide options to
> our users and ourselves.  For the latter, being able to host anything
> on an outside service means that if some component of infra goes down
> we could have mirrors already running and pulling from infra, or if
> for some reason somebody sues us or roots us or whatever we can pick
> up and move without much fuss.
>
> Running your own wiki/bugzilla/lists/etc was about the only way to do
> things in the 90s/etc, but these days there are other options...
>
"Cloud-based Gentoo" - yeah I see *absolutely no issues* with this ...





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Richard Yao]

> On Aug 5, 2018, at 1:01 PM, Alec Warner  wrote:
> 
> 
> 
>> On Sun, Aug 5, 2018 at 12:45 PM, Richard Yao  wrote:
>> 
>> 
>>> On Jun 23, 2018, at 6:59 AM, Alec Warner  wrote:
>>> 
>>> 
>>> 
 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.
>> This would put decision making power into the hands of bureaucrats. I would 
>> rather it remain in a community of volunteers.
> 
> Meh, it doesn't hurt to ask there about interest (they certainly fund 
> development of other components.) Its not like they have to accept, or that 
> declining somehow inhibits this development.
> 
> Part of my frustration is that seemingly "anything open source related can be 
> held in Gentoo" and I'm somewhat against that as I feel it dilutes the Gentoo 
> mission. We are here to make a distribution, not maintain random libraries. 
> If you want to do that feel free; but I don't see a need for that work to be 
> associated with Gentoo.

This could just be done as a downstream effort that carries patches without a 
subproject, but structuring it as a subproject would be a call for 
collaboration with other distributions, which would ultimately benefit us.

>  
>> 
>> I consider upstream development efforts by Gentoo developers to be 
>> beneficial to Gentoo. Nothing makes fixing an issue in Gentoo at upstream a 
>> priority quite like it affecting a key upstream developer in his day to day 
>> life.
>> 
>> 
>> Also, the Linux Foundation is not embarking on such a project and we clearly 
>> have someone willing to try, so I say that we should go for it. Having 
>> people that wish to take a more active role in upstream development would 
>> not make us any worse off. It is their time to volunteer, so it is not like 
>> they will volunteer it for something else if we discourage them.

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Richard Yao]

> On Aug 5, 2018, at 1:24 PM, Rich Freeman  wrote:
> 
>> On Sun, Aug 5, 2018 at 1:01 PM Alec Warner  wrote:
>> 
>> 
>> Part of my frustration is that seemingly "anything open source related
>> can be held in Gentoo" and I'm somewhat against that as I feel it
>> dilutes the Gentoo mission. We are here to make a distribution, not
>> maintain random libraries. If you want to do that feel free; but I
>> don't see a need for that work to be associated with Gentoo.
>> 
> 
> Honestly, other than maybe some prestige I don't really get the point
> of hosting random software in Gentoo either.  These days getting a
> repo on github or any of its 47 competitors is a few clicks.  You have
> zero overhead from a governance standpoint, and a dev can of course
> stick ebuilds in the main repository with zero interference.  It seems
> a lot cleaner from a copyright/etc standpoint as well.

Prestige is good. We have prestige from our (myself and a few others) work in 
upstream ZFS and Gentoo is well respected there. You will not hear binary 
package zealots bashing Gentoo in ZFS circles. If a sub-project that touches 
the entire OSS community can be even a tenth as effective as the efforts in ZFS 
have been in eliminating binary package zealotry, it would be well worth it.
> 
> Even openrc is hosted outside of Gentoo these days, which makes perfect sense.
> 
> With the distro as a whole it is a bit more complex, though honestly
> I'd love to see us get to a point where the whole thing can be
> SECURELY hosted entirely off-infra as well, even if we still chose to
> run our own infra.  I just see it as a way to both provide options to
> our users and ourselves.  For the latter, being able to host anything
> on an outside service means that if some component of infra goes down
> we could have mirrors already running and pulling from infra, or if
> for some reason somebody sues us or roots us or whatever we can pick
> up and move without much fuss.
> 
> Running your own wiki/bugzilla/lists/etc was about the only way to do
> things in the 90s/etc, but these days there are other options...
> 
> -- 
> Rich
> 

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Rich Freeman]

On Sun, Aug 5, 2018 at 2:12 PM Richard Yao  wrote:
>
>
> Prestige is good. We have prestige from our (myself and a few others) work in 
> upstream ZFS and Gentoo is well respected there.

Sure, but ZFS on Linux isn't a Gentoo project.

I'm not saying people who are Gentoo devs can't also do other things.
Lots of Gentoo devs are involved in lots of stuff that gets a fair bit
of respect. OpenRC is a big example of this.  From time to time I bump
into signs of Gentoo on upstream projects (just today that included
SoapySDRPlay).

Also, this gives us an opportunity to set an example, in helping to
ensure the upstream project is maintained in a distro-friendly manner
where Gentoo is a first class citizen.

I'm not saying that stuff like this should be banned from infra.  It
just seems like an unnecessary constraint all-around.  It means that
the project has to generally follow Gentoo policies/etc, and is
limited to the tools we provide.  Just something to think about...


-- 
Rich

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Richard Yao]

> On Aug 5, 2018, at 2:35 PM, Rich Freeman  wrote:
> 
>> On Sun, Aug 5, 2018 at 2:12 PM Richard Yao  wrote:
>> 
>> 
>> Prestige is good. We have prestige from our (myself and a few others) work 
>> in upstream ZFS and Gentoo is well respected there.
> 
> Sure, but ZFS on Linux isn't a Gentoo project.
> 
> I'm not saying people who are Gentoo devs can't also do other things.
> Lots of Gentoo devs are involved in lots of stuff that gets a fair bit
> of respect. OpenRC is a big example of this.  From time to time I bump
> into signs of Gentoo on upstream projects (just today that included
> SoapySDRPlay).
> 
> Also, this gives us an opportunity to set an example, in helping to
> ensure the upstream project is maintained in a distro-friendly manner
> where Gentoo is a first class citizen.
> 
> I'm not saying that stuff like this should be banned from infra.  It
> just seems like an unnecessary constraint all-around.  It means that
> the project has to generally follow Gentoo policies/etc, and is
> limited to the tools we provide.  Just something to think about...
Which policies would those be? The upstream projects that we do have as Gentoo 
sub-projects seem to have plenty of freedom.
> 
> 
> -- 
> Rich
> 

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2018-08-05 23:59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2018-08-05 23:59 UTC.

Removals:

Additions:
app-admin/spectre-meltdown-checker 20180801-23:23 candrews  c048710cd14
app-misc/mkcert20180730-12:37 mrueg cf834f85f7a
app-portage/gverify20180801-20:53 mgornyb640e0eb72b
dev-libs/nsync 20180804-03:14 perfinion 46a0f1dc980
dev-python/ansi20180801-12:59 pinkbyte  5e677253c3a
dev-python/daemonize   20180801-12:55 pinkbyte  76ee312b49e
dev-python/precis-i18n 20180731-23:00 aidecoe   eb3ddb110e1
dev-python/pytest-describe 20180804-20:20 whissi1af688711db
dev-python/python-cstruct  20180731-22:46 zmedico   ad00fcb37f0
dev-python/serverfiles 20180805-16:18 amynkadf9c050629b
media-libs/graphene20180730-09:12 leio  ba8ab2aec22
sys-auth/sakcl 20180805-22:06 cardoe12a00a8b93e
sys-auth/ssh-ldap-pubkey   20180804-20:21 whissi1a2d49ef9bf

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
Added Packages:
sys-auth/sakcl,added,cardoe,20180805-22:06,12a00a8b93e
dev-python/serverfiles,added,amynka,20180805-16:18,df9c050629b
sys-auth/ssh-ldap-pubkey,added,whissi,20180804-20:21,1a2d49ef9bf
dev-python/pytest-describe,added,whissi,20180804-20:20,1af688711db
dev-libs/nsync,added,perfinion,20180804-03:14,46a0f1dc980
app-admin/spectre-meltdown-checker,added,candrews,20180801-23:23,c048710cd14
dev-python/precis-i18n,added,aidecoe,20180731-23:00,eb3ddb110e1
app-portage/gverify,added,mgorny,20180801-20:53,b640e0eb72b
dev-python/ansi,added,pinkbyte,20180801-12:59,5e677253c3a
dev-python/daemonize,added,pinkbyte,20180801-12:55,76ee312b49e
dev-python/python-cstruct,added,zmedico,20180731-22:46,ad00fcb37f0
app-misc/mkcert,added,mrueg,20180730-12:37,cf834f85f7a
media-libs/graphene,added,leio,20180730-09:12,ba8ab2aec22

Done.