I've been rather busy lately and can't keep up with all of my packages.
There are pending bumps, some bugs, but nothing too crazy or hard. 
So I'm looking for someone to co-maintain (or even take over if you
insist) the following packages:

* net-mail/notmuch
pseudo-autoconf NIH build system that can be PITA to work with,
responsive upstream. High profile package.
proxied maintainer in metadata has not been active lately and probably
should be dropped.

* net-irc/weechat
Regular but not very frequent releases, responsive upstream, cmake,
pretty sane and very popular.

* dev-cpp/abseil-cpp
Googleware, it's usually bundled into source, like gnulib, but some
projects use system copy.
Hardcoded flags, broken abi every other bump, may require slotting in
the future, some revdeps rely on older versions. Not hard to maintain,
but has more that usual blast radius.

* net-libs/grpc
* dev-python/grpcio
* dev-python/grpcio-tools
* dev-python/grpcio-testing
grpc stack, googleware again. rather frequent releases, lack of
portage-able tests, as tests insist on downloading gtest stack git
master in src_test phase.
Technically it's already co-maintained, but I't be beneficial if we
have more hands and eyes on this one.
python project has been helping with python packages, but lack of tests
makes the package somewhat risky.
bonus points if you can test it with tensorflow.

* dev-util/bear
Responsive upstream. Tests work but require disabling sandboxing (check
ebuild on how to run it). Not too hard, pretty popular.

* app-arch/dpkg
debian upstream, easy to maintain. just need extra eyeballs.

* app-shells/fish
Responsive upstream, not very frequent releases, cmake. Requires some
attention on non-x86 as arch bugs are rather frequent. But nothing too
crazy.

* sys-process/glances
Responsive upstream, easy package. Just need extra pair of eyes/hands.

* dev-util/google-perftools
Another google package, very arch-specific, big blast radius if broken.
Not hard to maintain, but need to be extra careful with revdeps,
requires alt-arch testing.

* app-admin/sysstat
pretty easy but important package. I will also offer base-system to
take it, as it's kinda important one.

* app-admin/tmpreaper
debian upstream, easy.

* x11-misc/xwallpaper
sane upstream, easy package. just need extra hands. probably most
secure wallpaper setter out there ;-)


Thanks, Georgy.

PS. Huge bonus if you can test packages not only on x86_64.
Ofc I can help with some gotchas in packages and have no plans on
abandoning those completely, but realistically I'm not doing enough to
keep those properly maintained at the moment.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hey.

* net-irc/weechat
Regular but not very frequent releases, responsive upstream, cmake,
pretty sane and very popular.

I'm a proxied maintainer, but I can add my name to it, as I'm a user of the package. I'll submit a PR tomorrow to do so.

Cheers,
Zoltan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Jul 03, 2022 at 09:03:04PM -0700, Georgy Yakovlev wrote:

I've been rather busy lately and can't keep up with all of my packages.
There are pending bumps, some bugs, but nothing too crazy or hard. 
So I'm looking for someone to co-maintain (or even take over if you
insist) the following packages:

* dev-cpp/abseil-cpp
Googleware, it's usually bundled into source, like gnulib, but some
projects use system copy.
Hardcoded flags, broken abi every other bump, may require slotting in
the future, some revdeps rely on older versions. Not hard to maintain,
but has more that usual blast radius.

I'll take this, I already end up having to apply random patches to make
it play well with CUDA.

* net-libs/grpc
* dev-python/grpcio
* dev-python/grpcio-tools
* dev-python/grpcio-testing
grpc stack, googleware again. rather frequent releases, lack of
portage-able tests, as tests insist on downloading gtest stack git
master in src_test phase.
Technically it's already co-maintained, but I't be beneficial if we
have more hands and eyes on this one.
python project has been helping with python packages, but lack of tests
makes the package somewhat risky.
bonus points if you can test it with tensorflow.

I'm the co-maintainer on this already but as Georgy said, happy to have
other maintainers as well, I dont really interact with it other than via TensorFlow. If people use it as deps from other things that would be
great too :)

-- Jason

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Jul 03, 2022 at 09:03:04PM -0700, Georgy Yakovlev wrote:

I've been rather busy lately and can't keep up with all of my packages.
There are pending bumps, some bugs, but nothing too crazy or hard. 
So I'm looking for someone to co-maintain (or even take over if you
insist) the following packages:

* net-mail/notmuch
pseudo-autoconf NIH build system that can be PITA to work with,
responsive upstream. High profile package.
proxied maintainer in metadata has not been active lately and probably
should be dropped.

* net-irc/weechat
Regular but not very frequent releases, responsive upstream, cmake,
pretty sane and very popular.

* dev-cpp/abseil-cpp
Googleware, it's usually bundled into source, like gnulib, but some
projects use system copy.
Hardcoded flags, broken abi every other bump, may require slotting in
the future, some revdeps rely on older versions. Not hard to maintain,
but has more that usual blast radius.

* net-libs/grpc
* dev-python/grpcio
* dev-python/grpcio-tools
* dev-python/grpcio-testing
grpc stack, googleware again. rather frequent releases, lack of
portage-able tests, as tests insist on downloading gtest stack git
master in src_test phase.
Technically it's already co-maintained, but I't be beneficial if we
have more hands and eyes on this one.
python project has been helping with python packages, but lack of tests
makes the package somewhat risky.
bonus points if you can test it with tensorflow.

* dev-util/bear
Responsive upstream. Tests work but require disabling sandboxing (check ebuild on how to run it). Not too hard, pretty popular.

* app-arch/dpkg
debian upstream, easy to maintain. just need extra eyeballs.

* app-shells/fish
Responsive upstream, not very frequent releases, cmake. Requires some attention on non-x86 as arch bugs are rather frequent. But nothing too
crazy.

* sys-process/glances
Responsive upstream, easy package. Just need extra pair of eyes/hands.

Joined you here!

* dev-util/google-perftools
Another google package, very arch-specific, big blast radius if broken.
Not hard to maintain, but need to be extra careful with revdeps,
requires alt-arch testing.

* app-admin/sysstat
pretty easy but important package. I will also offer base-system to
take it, as it's kinda important one.

* app-admin/tmpreaper
debian upstream, easy.

* x11-misc/xwallpaper
sane upstream, easy package. just need extra hands. probably most
secure wallpaper setter out there ;-)

Thanks, Georgy.

PS. Huge bonus if you can test packages not only on x86_64.
Ofc I can help with some gotchas in packages and have no plans on
abandoning those completely, but realistically I'm not doing enough to
keep those properly maintained at the moment.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEElFuPenBj6NvNLoABXP0dAeB+IzgFAmLFD9sACgkQXP0dAeB+ IzhK+w//ZCZBhcju7llUEih/I4VqI49J5hHU19j482gaNNLGfF0whe9zscK4xjLl JCMJCLI4hex8OYaQTO3KgtK1i3Lz85rA2vY03bSfv7vOhuCFn/iGRcZpuSkmC14O QvoO8s5Ce9p9G4p14G9x+nlbS5nkBScA5U20ryHDp5IVumbzw1/Cc82v0SFkkiKV WRAeHKuK7ISH9J32zE+ig9Ets5342j38fqAfIKdn8Qu7uae8MQ7sdXgjdN7k6rau caC0CjpePivnVzQrOVbcwas5Q7mUnPs+SOc++40APUWkC+ooO6mCxwKSpqgyAT+N KWVxMf8Umg24YYnK4h3F5DXviXS8L5LeKLHq5cah8brQXA13Y0hBwGfTHGjNHsAQ MCkdfk2cg0DxT2Yu1qX8f/VpxkD8IN66rMwzjsHOSe4K9VOUfU4HtKz9zFPc4Ws9 V5tdWJzQJxadKGwkkPpr9EDo4Js+XNQcl1mnq2ViPS4LYGsNpRmPiHbt3OKqlooi 3JW/a2tIHjuYqcDHTKFpGSt5jzu/dhMHN7yuzMQpg45k9w19Fio7imKMi/G99H3j MOihCqLEwK3VKpH87Tm3PlJec3iJRKqVg3hvsXXnHoX9rSuIEKfTEUH3vievvoxf s3yM8Y50d6URKCFa2WbHujRo5g/dSLNzZbK/+twADZF8FhQjISk=
=5MWL
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Jul 03, 2022 at 09:03:04PM -0700, Georgy Yakovlev wrote:

I've been rather busy lately and can't keep up with all of my packages.
There are pending bumps, some bugs, but nothing too crazy or hard. 
So I'm looking for someone to co-maintain (or even take over if you
insist) the following packages:

Noob question, I would have to be a Gentoo developer/maintainer to help
with that, am I right?

* app-shells/fish
Responsive upstream, not very frequent releases, cmake. Requires some >attention on non-x86 as arch bugs are rather frequent. But nothing too
crazy.

Since I do not have any experience with official maintainership I would hesitate to commit to anything I am not a user of, but I do use fish and
keep an eye on releases a bit (which I would do more, of course).

[...]

PS. Huge bonus if you can test packages not only on x86_64.
Ofc I can help with some gotchas in packages and have no plans on
abandoning those completely, but realistically I'm not doing enough to
keep those properly maintained at the moment.

I can test that every now and then and even fix some possible issues, hopefully.

Let me know if I can be of help or whether I should rather go through
proxy maintainers or another route.

Have a nice day,
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

07.07.2022 11:27, Martin Kletzander пишет:

On Sun, Jul 03, 2022 at 09:03:04PM -0700, Georgy Yakovlev wrote:

I've been rather busy lately and can't keep up with all of my packages.
There are pending bumps, some bugs, but nothing too crazy or hard.
So I'm looking for someone to co-maintain (or even take over if you
insist) the following packages:

Noob question, I would have to be a Gentoo developer/maintainer to help
with that, am I right?

Don't worry, proxied maintainers can easily (co-)maintain packages too.

* app-shells/fish
Responsive upstream, not very frequent releases, cmake. Requires some
attention on non-x86 as arch bugs are rather frequent. But nothing too
crazy.

Since I do not have any experience with official maintainership I would hesitate to commit to anything I am not a user of, but I do use fish and
keep an eye on releases a bit (which I would do more, of course).

[...]

PS. Huge bonus if you can test packages not only on x86_64.
Ofc I can help with some gotchas in packages and have no plans on
abandoning those completely, but realistically I'm not doing enough to
keep those properly maintained at the moment.

I can test that every now and then and even fix some possible issues, hopefully.

Let me know if I can be of help or whether I should rather go through
proxy maintainers or another route.

It's possible for a particular developer to be the proxy, and it's
possible for p-m project to be proxies for the proxied maintainers.

Have a nice day,
Martin

--
Best regards,
Alexey "DarthGandalf" Sokolov

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)