[gentoo-dev] Reminder: open season on robbat2's packages

[gentoo-dev] Reminder: open season on robbat2's packages

[Robin H. Johnson]

Over the years, I've come to be the maintainer a huge number of
packages (~300 or so, and I just gave up ~100 of those back to relevant
herds). Many of them are from inheriting packages when other developers
have retired - the upstream may also be dead, but there is nothing that
supersedes the functionality of the package, so if I use it, it lives.

If you're a developer waiting for an action on one of them, and you've
attached a fix to a bug, you should mostly feel free to go ahead any
just apply your patch. If you break it, I'll hunt you down.

Exceptions:
dev-db/mariadb, dev-db/mysql - mysql herd
MogileFS,  Perlbal - me
sys-libs/db - base-system
LVM - please be careful!

Packages where I am the upstream:
app-admin/diradm
app-shells/localshell
sys-apps/readahead-list
dev-perl/WattsUp-Daemon

Packages sent for lastrite:
dev-vcs/gitosis-gentoo
dev-vcs/gitosis

Here's a list of every package where I'm a maintainer and there is no
herd listed (but their might be other maintainers):
app-admin/cancd
app-arch/duff
app-arch/unadf
app-backup/mirdir
app-crypt/af_alg
app-crypt/gpg-ringmgr
app-crypt/mhash
app-emulation/qenv
app-misc/ddccontrol-db
app-misc/ddccontrol
app-misc/dnetc
app-misc/egads
app-misc/interceptty
app-text/binfind
app-text/convmv
app-text/sloccount
app-text/unrtf
dev-cpp/threadpool
dev-db/libdbi-drivers
dev-db/libdbi
dev-db/redis
dev-lang/snobol
dev-libs/bglibs
dev-libs/libmcal
dev-libs/libmelf
dev-libs/libmemcached
dev-libs/libmemcache
dev-libs/OpenSRF
dev-libs/yaz
dev-util/checkbashisms
dev-util/fuzz
dev-util/idutils
dev-util/its4
dev-util/mpatch
dev-util/pscan
dev-util/rats
dev-util/re2c
dev-util/sgb
dev-util/wiggle
dev-vcs/cvs2svn
dev-vcs/git
media-gfx/monica
media-gfx/springgraph
media-sound/dbmeasure
net-analyzer/ipaudit
net-analyzer/poink
net-analyzer/raddump
net-analyzer/sslsniff
net-analyzer/thrulay
net-dns/ndu
net-firewall/ipset
net-libs/cvm
net-libs/libmonetra
net-mail/vqadmin
net-misc/adjtimex
net-misc/aggregate-flim
net-misc/aggregate
net-misc/dcetest
net-misc/ifenslave
net-misc/memcached
net-misc/netdate
net-misc/nstx
net-misc/openrdate
net-misc/pcapfix
net-misc/rdate
net-misc/tiers
net-misc/valve
net-misc/vmnet
net-misc/vmpsd
net-misc/zsync
net-nds/led
net-nds/nsscache
net-proxy/piper
net-wireless/bss
sys-apps/clrngd
sys-apps/hwinfo
sys-apps/input-utils
sys-apps/linux-misc-apps
sys-apps/usbmon
sys-auth/icmpdn
sys-auth/nss_ldap
sys-block/btrace
sys-block/fio
sys-block/scsiping
sys-block/scsirastools
sys-block/seekwatcher
sys-block/tw_cli
sys-fs/lvm2
sys-libs/openhpi
sys-power/iasl
sys-power/nut
sys-process/audit


-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Diego Elio Pettenò]

On 18/11/2012 03:11, Robin H. Johnson wrote:
> net-libs/libmonetra

Maybe time to get rid of this one?

https://bugs.gentoo.org/show_bug.cgi?id=341721

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Robin H. Johnson]

On Sun, Nov 18, 2012 at 08:11:49AM -0800, Diego Elio Pettenò wrote:
> On 18/11/2012 03:11, Robin H. Johnson wrote:
> > net-libs/libmonetra
> Maybe time to get rid of this one?
> https://bugs.gentoo.org/show_bug.cgi?id=341721
Gone.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Gilles Dartiguelongue]

Le dimanche 18 novembre 2012 à 11:11 +0000, Robin H. Johnson a écrit :
> net-nds/nsscache
> sys-auth/nss_ldap

If nobody else want them and I don't forget about them, I'll take care
of these.

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Arun Raghavan]

On 18 November 2012 16:41, Robin H. Johnson <robbat2@gentoo.org> wrote:
[...]
> media-sound/dbmeasure

I'll take this one, since it's tangentially related to PulseAudio.

Cheers,
--
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Robin H. Johnson]

On Mon, Nov 19, 2012 at 10:43:44AM +0530, Arun Raghavan wrote:
> On 18 November 2012 16:41, Robin H. Johnson <robbat2@gentoo.org> wrote:
> [...]
> > media-sound/dbmeasure
> I'll take this one, since it's tangentially related to PulseAudio.
Speaking of PA, are you still upstream? If so, can you please merge the
patch I submitted to the -discuss list?

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Arun Raghavan]

On 19 November 2012 11:00, Robin H. Johnson <robbat2@gentoo.org> wrote:
> On Mon, Nov 19, 2012 at 10:43:44AM +0530, Arun Raghavan wrote:
>> On 18 November 2012 16:41, Robin H. Johnson <robbat2@gentoo.org> wrote:
>> [...]
>> > media-sound/dbmeasure
>> I'll take this one, since it's tangentially related to PulseAudio.
> Speaking of PA, are you still upstream? If so, can you please merge the
> patch I submitted to the -discuss list?

Yep. It's on my review list for today. We've frozen master for now
though, so might only go into the next release.

--
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

On 11:11 Sun 18 Nov     , Robin H. Johnson wrote:
> Here's a list of every package where I'm a maintainer and there is no
> herd listed (but their might be other maintainers):
> dev-util/wiggle
> dev-vcs/cvs2svn

Suppose I could take these.

> dev-vcs/git

I'm hoping somebody is taking this?

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux <http://dberkholz.com>
Analyst, RedMonk <http://redmonk.com/dberkholz/>

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Robin H. Johnson]

On Thu, Nov 22, 2012 at 08:22:10PM -0600, Donnie Berkholz wrote:
> On 11:11 Sun 18 Nov     , Robin H. Johnson wrote:
> > Here's a list of every package where I'm a maintainer and there is no
> > herd listed (but their might be other maintainers):
I didn't say I was dropping any of the packages, merely making an
explicit list of packages I maintain, that other developers are welcome
to touch - if they want to take them over explicitly, that would be
great too.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

[gentoo-dev] open season on other-dev's packages -- policy change?

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 22/11/12 11:22 PM, Robin H. Johnson wrote:
> On Thu, Nov 22, 2012 at 08:22:10PM -0600, Donnie Berkholz wrote:
>> On 11:11 Sun 18 Nov     , Robin H. Johnson wrote:
>>> Here's a list of every package where I'm a maintainer and there
>>> is no herd listed (but their might be other maintainers):
> I didn't say I was dropping any of the packages, merely making an 
> explicit list of packages I maintain, that other developers are
> welcome to touch - if they want to take them over explicitly, that
> would be great too.
> 

..  For certain things, I think it would be very beneficial for this
to be true (other dev's welcome to touch) across the tree.  Maybe if
there is enough general support for it, we should change our default
of "never touch a maintainer's package without permission of the
maintainer/herd", to "OK to touch unless package metadata explicitly
requests not to" ...?  And we can put a tag in the metadata to
indicate this (or even to indicate what other dev's can and can't
touch -- ie, can touch *DEPEND, can bump EAPI, cannot add features,
cannot bump)?

Thoughts?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlCvhOkACgkQ2ugaI38ACPBU1QEAuvQb36mAwjUvZl3Q3BU6l7M5
yb/+F4V6AisF47Y5OI4A/jtvmb7LmyH5B4UAv9EAGySt39oY3XW23sGPWXzWMxXz
=egrZ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Rich Freeman]

On Fri, Nov 23, 2012 at 9:15 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
> ..  For certain things, I think it would be very beneficial for this
> to be true (other dev's welcome to touch) across the tree.  Maybe if
> there is enough general support for it, we should change our default
> of "never touch a maintainer's package without permission of the
> maintainer/herd", to "OK to touch unless package metadata explicitly
> requests not to" ...?  And we can put a tag in the metadata to
> indicate this (or even to indicate what other dev's can and can't
> touch -- ie, can touch *DEPEND, can bump EAPI, cannot add features,
> cannot bump)?

Honestly, I like the maintainer/herd system - it promotes some kind of
consistency and accountability.  If everybody just goes poking at
random ebuilds anytime they want to then that will tend to lead to
chaos.

Why not just do everything BUT commit the ebuild, and then just attach
the fixed ebuild to the bug instead?  That really isn't any more work
for those doing the work, it allows users affected by the bug to
download the fixed ebuild instantly if they want to, and it still
allows the maintainer to be a quality gateway.

Even making it voluntary for maintainers to invite help creates some
risk that users will be subjected to uncoordinated updates/etc.  If
you want to avoid that, then the checklist for changing random
packages will likely grow so large that nobody will do it anyway.

If you know a lot of about a package or a group of packages, just add
yourself as a maintainer...

Rich

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23/11/12 09:28 AM, Rich Freeman wrote:
> On Fri, Nov 23, 2012 at 9:15 AM, Ian Stakenvicius <axs@gentoo.org>
> wrote:
>> ..  For certain things, I think it would be very beneficial for
>> this to be true (other dev's welcome to touch) across the tree.
>> Maybe if there is enough general support for it, we should change
>> our default of "never touch a maintainer's package without
>> permission of the maintainer/herd", to "OK to touch unless
>> package metadata explicitly requests not to" ...?  And we can put
>> a tag in the metadata to indicate this (or even to indicate what
>> other dev's can and can't touch -- ie, can touch *DEPEND, can
>> bump EAPI, cannot add features, cannot bump)?
> 
> Honestly, I like the maintainer/herd system - it promotes some kind
> of consistency and accountability.  If everybody just goes poking
> at random ebuilds anytime they want to then that will tend to lead
> to chaos.
> 

I'm not suggesting to abandon that, just augment it a little.  There
are dev's that want strict do-not-touch-my-stuff control, and dev's
that don't really care.  Defining as such in metadata would keep a
persistent record.

I can think of two specific examples where this would be an advantage:

#1 - the init-script-license issue.  When I filed all of those bugs,
there were a few dev's that said to me "Do what you want to fix the
LICENSE= on your own", many others didn't but i'm guessing that didn't
mean they actually explicitly desired to control LICENSE=.  Similarly,
I have absolutely no problem at all of someone fixes LICENSE= in any
of my packages -- I set them properly as best I could and I try and
watch out for changes, but if there's someone that knows better I say
"just do it."

#2 - sub-slots and slot-operators.  Adoption of this will go a lot
faster if the maintainers of libraries had free reign to update
*DEPEND in rdeps when necessary.  Some of this already happens, but
having permission to adjust *DEPEND be explicitly listed would make it
go quicker still and not cause the inevitable arguments that it always
seems to..


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlCvivYACgkQ2ugaI38ACPCSxwEAhudOC/pqJhcDPj1LErF8C2f1
bPAYrfcdNRCnovPSS2sA/jhkGjgkPcBFIM/m4uMKq8hVmHqw5RDb86pljpJz+37P
=ihwa
-----END PGP SIGNATURE-----

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/23/2012 03:40 PM, Ian Stakenvicius wrote:
> On 23/11/12 09:28 AM, Rich Freeman wrote:
>> On Fri, Nov 23, 2012 at 9:15 AM, Ian Stakenvicius
>> <axs@gentoo.org> wrote:
>>> ..  For certain things, I think it would be very beneficial
>>> for this to be true (other dev's welcome to touch) across the
>>> tree. Maybe if there is enough general support for it, we
>>> should change our default of "never touch a maintainer's
>>> package without permission of the maintainer/herd", to "OK to
>>> touch unless package metadata explicitly requests not to" ...?
>>> And we can put a tag in the metadata to indicate this (or even
>>> to indicate what other dev's can and can't touch -- ie, can
>>> touch *DEPEND, can bump EAPI, cannot add features, cannot
>>> bump)?
> 
>> Honestly, I like the maintainer/herd system - it promotes some
>> kind of consistency and accountability.  If everybody just goes
>> poking at random ebuilds anytime they want to then that will tend
>> to lead to chaos.
> 
> 
> I'm not suggesting to abandon that, just augment it a little.
> There are dev's that want strict do-not-touch-my-stuff control, and
> dev's that don't really care.  Defining as such in metadata would
> keep a persistent record.
> 
> I can think of two specific examples where this would be an
> advantage:
> 
> #1 - the init-script-license issue.  When I filed all of those
> bugs, there were a few dev's that said to me "Do what you want to
> fix the LICENSE= on your own", many others didn't but i'm guessing
> that didn't mean they actually explicitly desired to control
> LICENSE=.  Similarly, I have absolutely no problem at all of
> someone fixes LICENSE= in any of my packages -- I set them properly
> as best I could and I try and watch out for changes, but if there's
> someone that knows better I say "just do it."

I'd rather say let's make a policy for this particular case. Changing
the license should not break any package, so there is no need for
review if you are sure about the fix.

Even if it turns out you were wrong... well.

> 
> #2 - sub-slots and slot-operators.  Adoption of this will go a lot 
> faster if the maintainers of libraries had free reign to update 
> *DEPEND in rdeps when necessary.  Some of this already happens,
> but having permission to adjust *DEPEND be explicitly listed would
> make it go quicker still and not cause the inevitable arguments
> that it always seems to..
> 

This might require bumping the EAPI which is not always safe, so it
should go through the maintainer unless he says there is no need to.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQr435AAoJEFpvPKfnPDWztTQIAKBMUFivjl1B/UOHoowzODsE
jFyl0b4gQVwpfSnrZnxcLFkq+oU41BdLvdl4jD7EkYAnLl9fmGTlCF2VjJoGHopg
g70hRXU/jpzJb5J2qNSfAbvg1maouD0Q/cld4QpNF8b6IN9afinGaeRHYpFp9xlL
EydqrNeQh06gCpKTzDbYEdcB27yRDESvHMQgrdtU4fFr1SRsAJw9o5Nf5o2CcgFH
XoO1T4g4HMs0B0w1oLU1YoCvXkmGP6fDRvcY5hpRQ8C/0LlEtoK4YuyIruOkMBLB
rQ+xuJulVm47Qdx1tv4Vb3dJM7gudOT+pyS2HQXqzAPiAMEPlxhDkqWlbYp5QCQ=
=UjuT
-----END PGP SIGNATURE-----

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]

Ian Stakenvicius schrieb:
> On 22/11/12 11:22 PM, Robin H. Johnson wrote:
>> On Thu, Nov 22, 2012 at 08:22:10PM -0600, Donnie Berkholz wrote:
>>> On 11:11 Sun 18 Nov     , Robin H. Johnson wrote:
>>>> Here's a list of every package where I'm a maintainer and there
>>>> is no herd listed (but their might be other maintainers):
>> I didn't say I was dropping any of the packages, merely making an 
>> explicit list of packages I maintain, that other developers are
>> welcome to touch - if they want to take them over explicitly, that
>> would be great too.
> 
> 
> ..  For certain things, I think it would be very beneficial for this
> to be true (other dev's welcome to touch) across the tree.  Maybe if
> there is enough general support for it, we should change our default
> of "never touch a maintainer's package without permission of the
> maintainer/herd", to "OK to touch unless package metadata explicitly
> requests not to" ...?  And we can put a tag in the metadata to
> indicate this (or even to indicate what other dev's can and can't
> touch -- ie, can touch *DEPEND, can bump EAPI, cannot add features,
> cannot bump)?
> 
> Thoughts?
> 
> 
> 

What certain things do you have in mind? In wich situation do you see a
simple "May i touch the package?/ok for this patch?" as too much to do
before touching a package?

-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23/11/12 09:32 AM, Thomas Sachau wrote:
> Ian Stakenvicius schrieb:
>> On 22/11/12 11:22 PM, Robin H. Johnson wrote:
>>> On Thu, Nov 22, 2012 at 08:22:10PM -0600, Donnie Berkholz
>>> wrote:
>>>> On 11:11 Sun 18 Nov     , Robin H. Johnson wrote:
>>>>> Here's a list of every package where I'm a maintainer and
>>>>> there is no herd listed (but their might be other
>>>>> maintainers):
>>> I didn't say I was dropping any of the packages, merely making
>>> an explicit list of packages I maintain, that other developers
>>> are welcome to touch - if they want to take them over
>>> explicitly, that would be great too.
>> 
>> 
>> ..  For certain things, I think it would be very beneficial for
>> this to be true (other dev's welcome to touch) across the tree.
>> Maybe if there is enough general support for it, we should change
>> our default of "never touch a maintainer's package without
>> permission of the maintainer/herd", to "OK to touch unless
>> package metadata explicitly requests not to" ...?  And we can put
>> a tag in the metadata to indicate this (or even to indicate what
>> other dev's can and can't touch -- ie, can touch *DEPEND, can
>> bump EAPI, cannot add features, cannot bump)?
>> 
>> Thoughts?
>> 
>> 
>> 
> 
> What certain things do you have in mind? In wich situation do you
> see a simple "May i touch the package?/ok for this patch?" as too
> much to do before touching a package?
> 

This works, and when, say, myself and the other dev are on irc it's
very quick, but then if I don't write it down or communicate it to my
other couterparts in the herd this permission gets lost in the
shuffle.  I'm just suggesting that if we put it in the metadata then
it'll be easier to track.

And -maybe- if the majority of dev's feel it appropriate, then we
switch "deny,allow x" to "allow,deny x".


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlCvjK8ACgkQ2ugaI38ACPDNggEArddTaH+ng/JhbH2AIq0ecI3n
qZipGtd4j8wmrQZIhz0BALVAsDcVOoBsrqGk2KpwGCag0o3QTSd/nx+4Y9i/Ddnw
=MbHC
-----END PGP SIGNATURE-----

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 2300 bytes --]

Ian Stakenvicius schrieb:
> On 23/11/12 09:32 AM, Thomas Sachau wrote:
>> Ian Stakenvicius schrieb:
>>> On 22/11/12 11:22 PM, Robin H. Johnson wrote:
>>>> On Thu, Nov 22, 2012 at 08:22:10PM -0600, Donnie Berkholz
>>>> wrote:
>>>>> On 11:11 Sun 18 Nov     , Robin H. Johnson wrote:
>>>>>> Here's a list of every package where I'm a maintainer and
>>>>>> there is no herd listed (but their might be other
>>>>>> maintainers):
>>>> I didn't say I was dropping any of the packages, merely making
>>>> an explicit list of packages I maintain, that other developers
>>>> are welcome to touch - if they want to take them over
>>>> explicitly, that would be great too.
>>>
>>>
>>> ..  For certain things, I think it would be very beneficial for
>>> this to be true (other dev's welcome to touch) across the tree.
>>> Maybe if there is enough general support for it, we should change
>>> our default of "never touch a maintainer's package without
>>> permission of the maintainer/herd", to "OK to touch unless
>>> package metadata explicitly requests not to" ...?  And we can put
>>> a tag in the metadata to indicate this (or even to indicate what
>>> other dev's can and can't touch -- ie, can touch *DEPEND, can
>>> bump EAPI, cannot add features, cannot bump)?
>>>
>>> Thoughts?
>>>
>>>
>>>
> 
>> What certain things do you have in mind? In wich situation do you
>> see a simple "May i touch the package?/ok for this patch?" as too
>> much to do before touching a package?
> 
> 
> This works, and when, say, myself and the other dev are on irc it's
> very quick, but then if I don't write it down or communicate it to my
> other couterparts in the herd this permission gets lost in the
> shuffle.  I'm just suggesting that if we put it in the metadata then
> it'll be easier to track.

You can already add a comment in the ebuild or metadata.xml to
explicitly allow everyone to touch it, so there is nothing needed to
allow you or anyone else interested in it doing this now.

Just reverting this default probably wont happen, since it just means
additional work and issues without any real benefit (like mass commits
to add the notes, missed additions and others touched the package and
other problems).

-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23/11/12 10:00 AM, Thomas Sachau wrote:
> Ian Stakenvicius schrieb:
>> On 23/11/12 09:32 AM, Thomas Sachau wrote:
>>> Ian Stakenvicius schrieb:
>>>> On 22/11/12 11:22 PM, Robin H. Johnson wrote:
>>>>> On Thu, Nov 22, 2012 at 08:22:10PM -0600, Donnie Berkholz 
>>>>> wrote:
>>>>>> On 11:11 Sun 18 Nov     , Robin H. Johnson wrote:
>>>>>>> Here's a list of every package where I'm a maintainer
>>>>>>> and there is no herd listed (but their might be other 
>>>>>>> maintainers):
>>>>> I didn't say I was dropping any of the packages, merely
>>>>> making an explicit list of packages I maintain, that other
>>>>> developers are welcome to touch - if they want to take them
>>>>> over explicitly, that would be great too.
>>>> 
>>>> 
>>>> ..  For certain things, I think it would be very beneficial
>>>> for this to be true (other dev's welcome to touch) across the
>>>> tree. Maybe if there is enough general support for it, we
>>>> should change our default of "never touch a maintainer's
>>>> package without permission of the maintainer/herd", to "OK to
>>>> touch unless package metadata explicitly requests not to"
>>>> ...?  And we can put a tag in the metadata to indicate this
>>>> (or even to indicate what other dev's can and can't touch --
>>>> ie, can touch *DEPEND, can bump EAPI, cannot add features,
>>>> cannot bump)?
>>>> 
>>>> Thoughts?
>>>> 
>>>> 
>>>> 
>> 
>>> What certain things do you have in mind? In wich situation do
>>> you see a simple "May i touch the package?/ok for this patch?"
>>> as too much to do before touching a package?
>> 
>> 
>> This works, and when, say, myself and the other dev are on irc
>> it's very quick, but then if I don't write it down or communicate
>> it to my other couterparts in the herd this permission gets lost
>> in the shuffle.  I'm just suggesting that if we put it in the
>> metadata then it'll be easier to track.
> 
> You can already add a comment in the ebuild or metadata.xml to 
> explicitly allow everyone to touch it, so there is nothing needed
> to allow you or anyone else interested in it doing this now.
> 
> Just reverting this default probably wont happen, since it just
> means additional work and issues without any real benefit (like
> mass commits to add the notes, missed additions and others touched
> the package and other problems).
> 
On 23/11/12 10:10 AM, hasufell wrote:
> I tend to agree with tommy. It's also difficult to reflect your
> attitude regarding your ebuilds being touched, cause it may differ
> depending on the subject of the change and who makes the change. So
> in the end it may boil down to a conversation anyway.
> 
> For things like your subslot example I am wondering if it could be 
> possible to do a dev-announce that packages will be touched by a
> group of devs, cause of important migration and that maintainers
> who don't feel comfortable with that can require a bug/patch.
> 
> While waiting for answers a few weeks you have the time to test
> that stuff in an overlay instead of reporting tons of bugs.


All good points.  Anyone else care to weigh in or does this seem to be
the consensus of everybody?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlCvlLYACgkQ2ugaI38ACPD9CAD9FTZBbNUlVDGMDTvojD49nmSq
lVz/ZJboibVwNSOWLXsA/jKs9taDeiPcXjArgTrvI5qxGvf/5V95zO0frjg0DCLU
=WKz3
-----END PGP SIGNATURE-----

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I tend to agree with tommy.
It's also difficult to reflect your attitude regarding your ebuilds
being touched, cause it may differ depending on the subject of the
change and who makes the change. So in the end it may boil down to a
conversation anyway.

For things like your subslot example I am wondering if it could be
possible to do a dev-announce that packages will be touched by a group
of devs, cause of important migration and that maintainers who don't
feel comfortable with that can require a bug/patch.

While waiting for answers a few weeks you have the time to test that
stuff in an overlay instead of reporting tons of bugs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQr5HrAAoJEFpvPKfnPDWzfCkIALNXbjH3xB6Mf837sVe8QM6q
xGuCJlivRlJLfbANHa058En2tVRV1qee373RXDmnsM6PBeU7rc8XLGxd0lM2lswD
48FCGo/8+AqBujLhY74FgXja/47b9WpcP3ZOw82/6bS8p4tcA5i665HHVbrLJ5VK
Wwri8BBlExj5y0HFrHS0KKMDAHLzbNEMDGArINa1w6iwx/3hVHkgaZVgxY3UZohH
D8A1BeTCoV5ZS3d890+BoVAYwCVKB6WiYfIdmpgmudweLgAmbqNkOnq8lQI88QmY
EWoLyibKSg7jzQ7e22IwNP/QFByvXf5SxfomsB6VRSJJyrYGLMI7W1GWHI2z1+Q=
=KoFo
-----END PGP SIGNATURE-----

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Patrick Lauer]

On 11/23/12 22:32, Thomas Sachau wrote:
> Ian Stakenvicius schrieb:
>> On 22/11/12 11:22 PM, Robin H. Johnson wrote:
>>> On Thu, Nov 22, 2012 at 08:22:10PM -0600, Donnie Berkholz wrote:
>>>> On 11:11 Sun 18 Nov     , Robin H. Johnson wrote:
>>>>> Here's a list of every package where I'm a maintainer and there
>>>>> is no herd listed (but their might be other maintainers):
>>> I didn't say I was dropping any of the packages, merely making an 
>>> explicit list of packages I maintain, that other developers are
>>> welcome to touch - if they want to take them over explicitly, that
>>> would be great too.
>>
>>
>> ..  For certain things, I think it would be very beneficial for this
>> to be true (other dev's welcome to touch) across the tree.  Maybe if
>> there is enough general support for it, we should change our default
>> of "never touch a maintainer's package without permission of the
>> maintainer/herd", to "OK to touch unless package metadata explicitly
>> requests not to" ...?  And we can put a tag in the metadata to
>> indicate this (or even to indicate what other dev's can and can't
>> touch -- ie, can touch *DEPEND, can bump EAPI, cannot add features,
>> cannot bump)?
>>
>> Thoughts?
>>
>>
>>
> 
> What certain things do you have in mind? In wich situation do you see a
> simple "May i touch the package?/ok for this patch?" as too much to do
> before touching a package?
> 
To me it's random noise, if I'm in the package metadata just do it. No
need to distract me :)

And there's tons of packages that have a "maintainer" in metadata and
bugs just go into nirvana (like apache)...

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/25/2012 02:01 AM, Patrick Lauer wrote:
> On 11/23/12 22:32, Thomas Sachau wrote:
>> Ian Stakenvicius schrieb:
>>> On 22/11/12 11:22 PM, Robin H. Johnson wrote:
>>>> On Thu, Nov 22, 2012 at 08:22:10PM -0600, Donnie Berkholz wrote:
>>>>> On 11:11 Sun 18 Nov     , Robin H. Johnson wrote:
>>>>>> Here's a list of every package where I'm a maintainer and there
>>>>>> is no herd listed (but their might be other maintainers):
>>>> I didn't say I was dropping any of the packages, merely making an 
>>>> explicit list of packages I maintain, that other developers are
>>>> welcome to touch - if they want to take them over explicitly, that
>>>> would be great too.
>>>
>>>
>>> ..  For certain things, I think it would be very beneficial for this
>>> to be true (other dev's welcome to touch) across the tree.  Maybe if
>>> there is enough general support for it, we should change our default
>>> of "never touch a maintainer's package without permission of the
>>> maintainer/herd", to "OK to touch unless package metadata explicitly
>>> requests not to" ...?  And we can put a tag in the metadata to
>>> indicate this (or even to indicate what other dev's can and can't
>>> touch -- ie, can touch *DEPEND, can bump EAPI, cannot add features,
>>> cannot bump)?
>>>
>>> Thoughts?
>>>
>>>
>>>
>>
>> What certain things do you have in mind? In wich situation do you see a
>> simple "May i touch the package?/ok for this patch?" as too much to do
>> before touching a package?
>>
> To me it's random noise, if I'm in the package metadata just do it. No
> need to distract me :)

I completely agree.  There is a lot of territorialism that is
*completely* unwarranted.  If you see an issue with one of my packages
and want to fix it, please, be my guest. Especially if it had a bug on
bugzie and you close that bug.  I get an email when my packages are
touched, if I don't like your change I'll tell you why and then fix it.
 If you horribly break my package, you may hear about it, but you
certainly won't get yelled at for fixing my bugs or bumping a package.

Thanks,
Zero
> 
> And there's tons of packages that have a "maintainer" in metadata and
> bugs just go into nirvana (like apache)...
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQsjykAAoJEKXdFCfdEflK0kUQAIB42lvd+oBP9xC9n9krkyzA
pIdQw/npCZtfQ4ZRXjkrhWf8uP9RkwB04qmFRO/DrxFlMu5QJ+wGPeu8zqRCJBri
GWqMATtZdvxHGeyKoAc/jJjp9+OHQ+izR7sGGo26uttj5QcA51e8e+568rw1xXk4
FQqQEOP9WXL8z8NOOo8ybv3SBqSg/+yHl05aInLhutKQAAtdOPy60nblGPMEyVIJ
deoMFUU5PsJRaAsHL30iBlclFpgn6UK8bdxTfMiXvEECUrAj+Hx6vSIh8cMPCdLq
SHT6Dcs8JkhKGEMX0v3CBzZ4yU/y36cSwNMah9eSFVnfW/R+7Mpt9Q3lfElwOSkl
OAtDqwEiyTgTG/ucOkFb+UBaAOpdlRsC0vbck5RDQaF3AWERpBx9AZ/qVjRg39jt
Yn7iads9FUAtrQ5bgMxHPkDlzNF50R99Ud41rJ1vZwl0JdrAgem5Pt2cO6TPEeZ8
6SeyVYQdRpqO3fMi6ijYTZEPiIX+EUJ8RkunUwgMHAhcn2IeAtkbbY5a3+1V2wpm
lIP5di6TujmlX7x9zy6UI2ItSnvlwX/rq2XkPOyo4j+wyyQJN4VD2QT4wERuDADK
ICJA/yke8tmsVo3Uxjtv8Yqbuug/AvD9blxlLpEPcuY5XKZOsxzzQFeRG7u5S+aZ
16yQHoOjDNFN9882Ggy5
=D8vW
-----END PGP SIGNATURE-----

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Rich Freeman]

On Sun, Nov 25, 2012 at 10:43 AM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
>  If you horribly break my package, you may hear about it, but you
> certainly won't get yelled at for fixing my bugs or bumping a package.

While I think there is a balance to be found, keep in mind that you as
the developer aren't the only person impacted if somebody breaks a
package you maintain.  Perhaps your users would prefer that people
with less experience with the package not fiddle with it.

If a package has a responsive maintainer, then pinging them isn't
really much of a hurdle.  If the package doesn't have a responsive
maintainer, then perhaps that should be fixed.

I'm not saying that there shouldn't be some way for maintainers to
indicate when they're willing to allow others to touch packages
without asking.  I'm just saying that this isn't purely a matter of
maintainer preference, or territorialism.

Rich

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/25/2012 10:51 AM, Rich Freeman wrote:
> On Sun, Nov 25, 2012 at 10:43 AM, Rick "Zero_Chaos" Farina
> <zerochaos@gentoo.org> wrote:
>>  If you horribly break my package, you may hear about it, but you
>> certainly won't get yelled at for fixing my bugs or bumping a package.
> 
> While I think there is a balance to be found, keep in mind that you as
> the developer aren't the only person impacted if somebody breaks a
> package you maintain.  Perhaps your users would prefer that people
> with less experience with the package not fiddle with it.
The developer fiddling with it needs to be confident they know what they
are doing (or at least have discussed it with more experienced
developers) before they "fiddle" with my packages.  My open invitation
for help should not be mistaken for an open invitation to experiment
with my packages.
> 
> If a package has a responsive maintainer, then pinging them isn't
> really much of a hurdle.  If the package doesn't have a responsive
> maintainer, then perhaps that should be fixed.
The problem is what of people like me, some weeks I'm very responsive
(seconds to minutes) while other times I'm away from a computer for the
entire week with no warning.  I don't want people waiting to fix
something easy because they are being polite to me.  As you said, what
of my users? Do they feel it's good to "wait a week" (something I hear
all the time) for a simple fix simply because no one could reach me?  I
think not.
> 
> I'm not saying that there shouldn't be some way for maintainers to
> indicate when they're willing to allow others to touch packages
> without asking.  I'm just saying that this isn't purely a matter of
> maintainer preference, or territorialism.

There shouldn't need to be a way for maintainers to indicate they are
willing to allow others to touch packages without asking, in my opinion
this should be the norm.

Again, no one should be randomly experimenting with someone else's
packages without asking, but fixes for obvious or even non-obvious
issues should be WELCOMED by all devs.  If you have a bug on bugzie that
is more than a week old and it affects me, you can bet I will fix it and
the notification you get will be the one from me closing your bug.  If
you have an issue with that maybe you should fix your own bugs.

When I say things like that I've had other devs "threaten" to find and
file bugs in my packages and then fix those bugs without asking me.
Really? Pretty please! If you see something I've missed you are welcome
to 1.) file a bug 2.) fix the bug if I'm not (nearly) immediately
responsive to assist.  I think this practice (overall) will improve
Gentoo for our users, and at the end of the day that's the only thing
that matters, not my ego.

Thanks,
Zero

PS> If you need an explicit "you are permitted to touch my packages"
then here it is, signed with my gpg key and everything. Find my bugs,
fix my bugs, try really hard not to break things. Thanks for your help.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQslukAAoJEKXdFCfdEflKo/EQAKD4SNghLvMrEiNnEztnKbFu
pKCcSMReTlsnXbFiO4itrI9KqgwdKCh4kGLfza1pSU6OEkVWM9H0vC1N/E0drFpL
at2MYEQF8qW4xKebDV0NCzmTDxjvDtx5/XQVSmp53Xi4XWb0FWd2X2mn1I+frm/i
uHYlsUKwF6852/605k2+h3Z++svc4UBR7V63XNY0wsgOYsJlmrFg1fQxLCCgcGUS
qFhgMT+bgYUh5gceJwCtHomHdxN/D+In1ILZWwHwWalyNSg/nDN7sZrGde+5dSZ5
9MkBL/NqxaSwTsYUX0xly0/52QDVrNVEMJBN8rxcMT83Cw/w7yoNoBaa/nEmtlej
/UK9mOYE/+fNNWVOERiOv4t3YTvdq6B5kP+xAeG+P3jEq54U43mK/fEAH1chPRQG
j4dMuSWAGuMgiAzbdVwfK2OawB1z321V8JzsUHb7P91javqjlP1GHPWAE95+PMZn
6mEAGXrRGmUpyC/ihZnsjhMdg1n8SLf6V1HIMvGxXEbiY22vFf7PcYP7bkWvSOyP
9EiKLB3d1Cu0lfo75telmrCBRBndrziD+UAe9C0fSjizxGK2tsE+kivZZ9yf+vS+
BrtGNtRiH9Je2ugakgpjgFrVjbAPmqUQqGshWuEqBQOHi5HzTE/YcO63w0wjHJPx
Y8IrzQvqPcUKp1t28ofN
=ZtW0
-----END PGP SIGNATURE-----

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Rich Freeman]

On Sun, Nov 25, 2012 at 12:55 PM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> If you have a bug on bugzie that
> is more than a week old and it affects me, you can bet I will fix it and
> the notification you get will be the one from me closing your bug.  If
> you have an issue with that maybe you should fix your own bugs.

If you want to co-maintain a package, then ping the current maintainer
and add yourself to the maintainer list.  You can then stay in touch
with them and coordinate plans for keeping the package working.

Suppose that developer has the fix standing by, but is working on
something else and wants to fix both issues at once to cut down on
revbumps?  Maybe they have a few week's worth handy and were waiting
for the right moment.

The fact is that the behavior you are bragging about is in violation
of policy.  If you don't like the policy by all means chime in and
discuss it, or ask the council to take it up.

This isn't about being territorial.  If you want to help co-maintain a
package I maintain you're welcome to do so.  However, this is a
long-term commitment.  Otherwise, send me an email before you go
messing with things.  If you're doing tree-wide work then coordinate
it with the appropriate project lead and make announcements on
-dev-announce as needed.  Nobody wants to stand in the way of getting
bugs fixed - there is just a way to do it so that you don't drive
everybody crazy.

Rich

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/25/2012 02:59 PM, Rich Freeman wrote:
> On Sun, Nov 25, 2012 at 12:55 PM, Rick "Zero_Chaos" Farina 
> <zerochaos@gentoo.org> wrote:
>> If you have a bug on bugzie that is more than a week old and it
>> affects me, you can bet I will fix it and the notification you
>> get will be the one from me closing your bug.  If you have an
>> issue with that maybe you should fix your own bugs.
> 
> If you want to co-maintain a package, then ping the current
> maintainer and add yourself to the maintainer list.  You can then
> stay in touch with them and coordinate plans for keeping the
> package working.
> 
> Suppose that developer has the fix standing by, but is working on 
> something else and wants to fix both issues at once to cut down on 
> revbumps?  Maybe they have a few week's worth handy and were
> waiting for the right moment.
> 
> The fact is that the behavior you are bragging about is in
> violation of policy.  If you don't like the policy by all means
> chime in and discuss it, or ask the council to take it up.

Please cite this policy so that I may do as you suggest. I have seen
no such policy.
> 
> This isn't about being territorial.  If you want to help
> co-maintain a package I maintain you're welcome to do so.  However,
> this is a long-term commitment.  Otherwise, send me an email before
> you go messing with things.  If you're doing tree-wide work then
> coordinate it with the appropriate project lead and make
> announcements on -dev-announce as needed.  Nobody wants to stand in
> the way of getting bugs fixed - there is just a way to do it so
> that you don't drive everybody crazy.

Your opinion on your packages is noted, and I will still be happy to
file bugs for you if I detect any issues with your packages the same
as I do for everyone else.

Thanks,
Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQspkYAAoJEKXdFCfdEflKGt4P/RlnOt1R6tzedkYxEdv4jbt3
3pO6fGkvs4Dmxwk5RXk+9H+TvWgUm07paAVhRzLBwDZP2MZf/mtbcOjj1uLh/2Kg
+kRsmNADZwojWzky72ksZXiEe60Nm/m3RAnqO2t2nrO6IyWa1BoN0h0D1rkdRFLD
ACPoznyXgENPKvLXW9e6RC9EM9AuCOWz1XQuy8QpR/UD+JX/DVWrQPLTX/i6t4uu
5docdxhFPrrCt+/goKyYBSSNku0/bhduNIOLIOxsPxnFbSMUxQD0C3ppdmDS/UIm
NnspNNk5LIrE7y5Dr6dVfZjpUP8QJjA/L6uNd8EsXSLrSuzp1ZfB2HwwGnWnnkCp
gKWKptQ5O8HkGrvCLG2q5BVqnvHP2d6SARXE4X3aCCikG5Npt2F//lCdu5ET0ekX
ia2L97FkZtUXbmbUfY1tCOgUq9ImR4gHxBTojSgdZ0ap9fAHDA5SD0sK50eKvWq/
d9JAO7+ITegX+PneOiJbHP9PNz4vWVbCzY0XtTHaCNzL+3jOyHJXXf3SpAP7mU+C
LfMKOjdtEZFHLevm+bT6oFTS6AKRYFspe+snsXH3ciItD8ANRqsjeqqkwBXDJqH3
lkzml+SgYHQre3JhhtDQ+8AyRNjQ88Uf0tE1AslhAwgC18B21pTZQdSNcF2w7UvM
rV2LFMwpH80/zOath7Y5
=BBmQ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Peter Stuge]

Rich Freeman wrote:
> If a package has a responsive maintainer, then pinging them isn't
> really much of a hurdle.

I'm not so sure. Waiting for a human round trip which due merely to
time zones might occupy my attention for 24 hours (even if I
obviously do other things meanwhile) is IMO quite significantly
different from the 24 seconds it might take for me to commit a fix.


//Peter

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]

On Thu, 31 Oct 2013 18:08:25 +0100
Peter Stuge <peter@stuge.se> wrote:

> Rich Freeman wrote:
> > If a package has a responsive maintainer, then pinging them isn't
> > really much of a hurdle.
> 
> I'm not so sure. Waiting for a human round trip which due merely to
> time zones might occupy my attention for 24 hours (even if I
> obviously do other things meanwhile) is IMO quite significantly
> different from the 24 seconds it might take for me to commit a fix.

For really severe bugs I think that pinging just anyone who is around
will do, alternatively you could ping the proxy maintainers herd. In
both cases there is most of the time someone available; so, it would be
a matter of minutes to have the patch applied.

And for bugs that can wait, it doesn't really matter that there is a
slight delay; with a ping where you provide a patch it is still fixed
faster than the average bug on bugzilla (assuming maintainer has time).

Please note that the average commit takes longer than 24 seconds as it
involves testing the change, repoman checks and similar QA matters.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]

Tom Wijsman wrote:
> For really severe bugs I think that pinging just anyone who is around
> will do, alternatively you could ping the proxy maintainers herd. In
> both cases there is most of the time someone available; so, it would be
> a matter of minutes to have the patch applied.

You're changing the subject. Nobody was talking about really severe
bugs, and those aren't really the common case. Normal bugs which have
to wait for the maintainer is quite likely to take much longer than
simply committing the (correct) bugfix.


> And for bugs that can wait, it doesn't really matter that there is a
> slight delay; with a ping where you provide a patch it is still fixed
> faster than the average bug on bugzilla (assuming maintainer has time).

Maybe delays don't matter to you, but you can't posit that the same
is true for every other developer. I think the potentially significant
delay matters a lot.

The whole point is that we cannot assume that maintainer has time.

The scenario is that I have taken a little time right now to fix a
bug and get the fix committed so that I no longer experience said bug.
I'm fixing this bug because it is blocking me in some way. It matters
a whole lot if I have to wait for someone else to unblock me, in
practice that completely demotivates me to contribute back, and I
would simply work around the block.


> Please note that the average commit takes longer than 24 seconds as it
> involves testing the change, repoman checks and similar QA matters.

QA has nothing to do with committing, don't confuse Gentoo policy
with actual meaning of the terms. Testing, repoman and QA matters
are of course part of creating the patch in the first place.

Maybe you can understand the point that I wanted to make even if I
was off by a factor of say 4. The delay is still three orders of
magnitude longer.


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 425 bytes --]

Peter Stuge wrote:
> It matters a whole lot if I have to wait for someone else to
> unblock me, in practice that completely demotivates me to
> contribute back, and I would simply work around the block.

To clarify this point; contributing fixes back must always be the
least effort of all ways to implement the fix in my own system.
Optimize for the (desired) common case. Anything else pushes
contributions away.


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Alon Bar-Lev]

On Fri, Nov 1, 2013 at 9:53 PM, Peter Stuge <peter@stuge.se> wrote:
> Peter Stuge wrote:
>> It matters a whole lot if I have to wait for someone else to
>> unblock me, in practice that completely demotivates me to
>> contribute back, and I would simply work around the block.
>
> To clarify this point; contributing fixes back must always be the
> least effort of all ways to implement the fix in my own system.
> Optimize for the (desired) common case. Anything else pushes
> contributions away.

Hi,

Just for me to understand, do you suggest everyone can commit into the tree?

Or do you want to join in as a developer?

Or something else?

Regards,
Alon Bar-Lev.

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Peter Stuge]

Alon Bar-Lev wrote:
> >> It matters a whole lot if I have to wait for someone else to
> >> unblock me, in practice that completely demotivates me to
> >> contribute back, and I would simply work around the block.
> >
> > To clarify this point; contributing fixes back must always be the
> > least effort of all ways to implement the fix in my own system.
> > Optimize for the (desired) common case. Anything else pushes
> > contributions away.
> 
> Just for me to understand, do you suggest everyone can commit into
> the tree?
> 
> Or do you want to join in as a developer?
> 
> Or something else?

I'm discussing the policies for Gentoo developers, stating my
preferences and opinions under the assumption that my contributions
to such a discussion are receivable and maybe even appreciated
regardless of whether I ever become a developer or not.


//Peter

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Alon Bar-Lev]

On Fri, Nov 1, 2013 at 10:06 PM, Peter Stuge <peter@stuge.se> wrote:
> Alon Bar-Lev wrote:
>> >> It matters a whole lot if I have to wait for someone else to
>> >> unblock me, in practice that completely demotivates me to
>> >> contribute back, and I would simply work around the block.
>> >
>> > To clarify this point; contributing fixes back must always be the
>> > least effort of all ways to implement the fix in my own system.
>> > Optimize for the (desired) common case. Anything else pushes
>> > contributions away.
>>
>> Just for me to understand, do you suggest everyone can commit into
>> the tree?
>>
>> Or do you want to join in as a developer?
>>
>> Or something else?
>
> I'm discussing the policies for Gentoo developers, stating my
> preferences and opinions under the assumption that my contributions
> to such a discussion are receivable and maybe even appreciated
> regardless of whether I ever become a developer or not.
>

Sure, but I may missed what you recommended...  not exist in the thread...

Blind commit without review of maintainer?
More maintainers?
More proxies?

I understand that you want to shorten the time between bug opening and
commit... but I do not understand what you suggest...

>
> //Peter
>

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 274 bytes --]

On Fri, 1 Nov 2013 22:11:38 +0200
Alon Bar-Lev <alonbl@gentoo.org> wrote:
> I understand that you want to shorten the time between bug opening and
> commit... but I do not understand what you suggest...

Switching to Git would be a good start.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

On 11/01/2013 04:14 PM, Ciaran McCreesh wrote:
> On Fri, 1 Nov 2013 22:11:38 +0200
> Alon Bar-Lev <alonbl@gentoo.org> wrote:
>> I understand that you want to shorten the time between bug opening and
>> commit... but I do not understand what you suggest...
> 
> Switching to Git would be a good start.
> 

The original source need not be under version control at all for the
purpose of writing patches. You just need to do `git init && git add -A
&& git commit -m initial` and your directory is under version control.
Then you can patch it to your heart's content until you are happy with it.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

On Fri, 01 Nov 2013 18:05:20 -0400
Richard Yao <ryao@gentoo.org> wrote:
> On 11/01/2013 04:14 PM, Ciaran McCreesh wrote:
> > On Fri, 1 Nov 2013 22:11:38 +0200
> > Alon Bar-Lev <alonbl@gentoo.org> wrote:
> >> I understand that you want to shorten the time between bug opening
> >> and commit... but I do not understand what you suggest...
> > 
> > Switching to Git would be a good start.
> > 
> 
> The original source need not be under version control at all for the
> purpose of writing patches. You just need to do `git init && git add
> -A && git commit -m initial` and your directory is under version
> control. Then you can patch it to your heart's content until you are
> happy with it.

The point is that git makes it super-easy to contribute patches, both
for users and for developers.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Maciej Mrozowski]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

On Friday 01 of November 2013 22:13:04 Ciaran McCreesh wrote:

| The point is that git makes it super-easy to contribute patches, both
| for users and for developers.

Well, it's not like one cannot submit patches against portage tree patches already..
And git is only super-convenient when combined with proper review tool, preferably with 'auto-push'.  But then again who would honestly 'trust' user-submitted merge request without trying to 'QA'* the package himself? The 'need' to check it myself delays user submissions in my case anyway.

(moving to git would likely help with shortening the cycle when combined with having 'overlays' being git clones of official gentoo-x86. I'm afraid however whole 'atomic' tree is just too huge to be practically cloned. Maybe Exherbo-like concept of project-specific git repos would work but splitting gentoo-x86 would sounds like a revolution)

* - looking for possible automagic in buildsystem, checking installed filelist

regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

On Fri, 1 Nov 2013 20:53:53 +0100
Peter Stuge <peter@stuge.se> wrote:

> To clarify this point; contributing fixes back must always be the
> least effort of all ways to implement the fix in my own system.
> Optimize for the (desired) common case. Anything else pushes
> contributions away.

Version control systems (eg. git) show otherwise.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 660 bytes --]

On 11/01/2013 05:18 PM, Tom Wijsman wrote:
> On Fri, 1 Nov 2013 20:53:53 +0100
> Peter Stuge <peter@stuge.se> wrote:
> 
>> To clarify this point; contributing fixes back must always be the
>> least effort of all ways to implement the fix in my own system.
>> Optimize for the (desired) common case. Anything else pushes
>> contributions away.
> 
> Version control systems (eg. git) show otherwise.

While I agree, I do not think this is a very constructive remark. Here
is a link to documentation that shows how to do this.

https://www.kernel.org/pub/software/scm/git/docs/git-send-email.html#_example

It is fairly easy once you know how.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]

On Fri, 01 Nov 2013 18:02:28 -0400
Richard Yao <ryao@gentoo.org> wrote:

> On 11/01/2013 05:18 PM, Tom Wijsman wrote:
> > On Fri, 1 Nov 2013 20:53:53 +0100
> > Peter Stuge <peter@stuge.se> wrote:
> > 
> >> To clarify this point; contributing fixes back must always be the
> >> least effort of all ways to implement the fix in my own system.
> >> Optimize for the (desired) common case. Anything else pushes
> >> contributions away.
> > 
> > Version control systems (eg. git) show otherwise.
> 
> While I agree, I do not think this is a very constructive remark. Here
> is a link to documentation that shows how to do this.
> 
> https://www.kernel.org/pub/software/scm/git/docs/git-send-email.html#_example
> 
> It is fairly easy once you know how.

Hmm, it perhaps isn't clear from what I wrote, but I meant that to be
general; thus the whole set of forking, pulling, pushing, merging, ...

I can't go and link all those; or well, maybe I can by just pointing to
the documentation but that would be a rather pointless addition.

Since a lot of people all across the world use git to contribute; my
answer meant to argue that it doesn't push contributions away, but
rather make them easier to do and maintain.

There isn't a general direct correlation between effort and efficiency;
so, sometimes by doing a little bit more effort, one can become way
more efficient at doing things. If effort isn't the selling point of
contributing, then efficiency will be; it depends on the way you look
at it. I do however have to agree there are people that see a version
control system as a barrier. There is no one size that fits all...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]

On Fri, 1 Nov 2013 20:49:36 +0100
Peter Stuge <peter@stuge.se> wrote:

> You're changing the subject. Nobody was talking about really severe
> bugs, and those aren't really the common case.

Nobody has to for them to be an exception worth mentioning.

> Maybe delays don't matter to you, but you can't posit that the same
> is true for every other developer. I think the potentially significant
> delay matters a lot.

Do you have an example? Which actual problem are we trying to fix here?

> The whole point is that we cannot assume that maintainer has time.

We can, because we have the devaway system.

> The scenario is that I have taken a little time right now to fix a
> bug and get the fix committed so that I no longer experience said bug.
> I'm fixing this bug because it is blocking me in some way. It matters
> a whole lot if I have to wait for someone else to unblock me, in
> practice that completely demotivates me to contribute back, and I
> would simply work around the block.

Delay is to be expected with proxy maintenance.

Why do you need to wait for the actual commit? If you have it
fixed locally, it does no longer bother you; does it?

> QA has nothing to do with committing, don't confuse Gentoo policy
> with actual meaning of the terms. Testing, repoman and QA matters
> are of course part of creating the patch in the first place.

It does, the person whom commits has to do the testing / repoman / QA;
ensuring the changes are good is the responsibility of the person whom
commits and that cannot be transferred to the writer of the patch.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Richard Yao]

On Nov 1, 2013, at 5:13 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>> QA has nothing to do with committing, don't confuse Gentoo policy
>> with actual meaning of the terms. Testing, repoman and QA matters
>> are of course part of creating the patch in the first place.
> 
> It does, the person whom commits has to do the testing / repoman / QA;
> ensuring the changes are good is the responsibility of the person whom
> commits and that cannot be transferred to the writer of the patch.

People learn during the recruitment process that every Gentoo developer is expected to perform basic repoman, build and run tests on each commit before making it. If anyone is not doing this, I imagine that the QA team would like to know so that they can be taken aside and flogged.

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]

On 11/25/2012 02:01 AM, Patrick Lauer wrote:
> On 11/23/12 22:32, Thomas Sachau wrote:
>> Ian Stakenvicius schrieb:
>>> On 22/11/12 11:22 PM, Robin H. Johnson wrote:
>>>> On Thu, Nov 22, 2012 at 08:22:10PM -0600, Donnie Berkholz wrote:
>>>>> On 11:11 Sun 18 Nov     , Robin H. Johnson wrote:
>>>>>> Here's a list of every package where I'm a maintainer and there
>>>>>> is no herd listed (but their might be other maintainers):
>>>> I didn't say I was dropping any of the packages, merely making an 
>>>> explicit list of packages I maintain, that other developers are
>>>> welcome to touch - if they want to take them over explicitly, that
>>>> would be great too.
>>>
>>>
>>> ..  For certain things, I think it would be very beneficial for this
>>> to be true (other dev's welcome to touch) across the tree.  Maybe if
>>> there is enough general support for it, we should change our default
>>> of "never touch a maintainer's package without permission of the
>>> maintainer/herd", to "OK to touch unless package metadata explicitly
>>> requests not to" ...?  And we can put a tag in the metadata to
>>> indicate this (or even to indicate what other dev's can and can't
>>> touch -- ie, can touch *DEPEND, can bump EAPI, cannot add features,
>>> cannot bump)?
>>>
>>> Thoughts?
>>>
>>>
>>>
>>
>> What certain things do you have in mind? In wich situation do you see a
>> simple "May i touch the package?/ok for this patch?" as too much to do
>> before touching a package?
>>
> To me it's random noise, if I'm in the package metadata just do it. No
> need to distract me :)
> 
> And there's tons of packages that have a "maintainer" in metadata and
> bugs just go into nirvana (like apache)...
> 

Too many bugs, not enough time. I am sure that the maintainers on those
will be thrilled to receive patches.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

On 04:22 Fri 23 Nov     , Robin H. Johnson wrote:
> On Thu, Nov 22, 2012 at 08:22:10PM -0600, Donnie Berkholz wrote:
> > On 11:11 Sun 18 Nov     , Robin H. Johnson wrote:
> > > Here's a list of every package where I'm a maintainer and there is no
> > > herd listed (but their might be other maintainers):
> I didn't say I was dropping any of the packages, merely making an
> explicit list of packages I maintain, that other developers are welcome
> to touch - if they want to take them over explicitly, that would be
> great too.

Gah, my bad, trying to run through email too fast.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux <http://dberkholz.com>
Analyst, RedMonk <http://redmonk.com/dberkholz/>

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Reminder: open season on robbat2's packages

[Robin H. Johnson]

Hi all,

Since it's been nearly a year since I last sent this email (and I got poked
with a stick about this), it's time for a reminder. I hope that in future, if
we get a non-maintainer update GLEP [1], this will become unneeded, as it can
be on api.gentoo.org.

1. http://thread.gmane.org/gmane.linux.gentoo.devel/86359

Over the years, I've come to be the maintainer a huge number of packages (300+)
Many of them are from inheriting packages when other developers have retired -
the upstream may also be dead, but there is nothing that supersedes the
functionality of the package, so if I use it, it lives.

If you're a developer waiting for an action on one of them, and you've attached
a fix to a bug, you should mostly feel free to go ahead any just apply your
patch. If you break it, I'll hunt you down. 

If you think you want to take over the package instead, or it should go for
last-rites/tree-cleaners etc; please claim it here or drop me an email; or for
the last category: just take it and leave a note.

Notable changes from last year:
- I'm releasing mogilefs and perlbal.
- new category of stuff people are welcome to take.

Exceptions:
dev-db/mariadb, dev-db/mysql - mysql herd
sys-libs/db - base-system
sys-fs/lvm2 - please be careful!

Packages where I am the upstream, and feature requests probably won't go far
without large good patches:
app-admin/diradm
app-shells/localshell
sys-apps/readahead-list
dev-perl/WattsUp-Daemon

Packages for tree-cleaner consideration:
dev-vcs/gitosis
dev-vcs/gitosis-gentoo
net-mail/vqadmin

Here's a list of every package where I'm a maintainer and there is no herd
listed (but their might be other maintainers), and I slightly care about the
package:
app-admin/cancd
app-arch/duff
app-arch/unadf
app-backup/mirdir
app-crypt/af_alg
app-crypt/gpg-ringmgr
app-crypt/mhash
app-misc/ddccontrol
app-misc/egads
app-misc/g15composer
app-misc/g15daemon
app-misc/g15macro
app-misc/g15message
app-misc/g15stats
app-misc/gcalcli
app-text/sloccount
app-text/unrtf
dev-libs/libg15
dev-libs/libg15render
dev-libs/libmcal
dev-libs/libmelf
dev-libs/libmemcache
dev-libs/libmemcached
dev-python/google-api-python-client
dev-vcs/cvs2svn
dev-vcs/git
net-analyzer/ipaudit
net-analyzer/ipv6-toolkit
net-analyzer/poink
net-analyzer/raddump
net-analyzer/sslsniff
net-analyzer/thrulay
net-dns/ndu
net-misc/adjtimex
net-misc/aggregate
net-misc/aggregate-flim
net-misc/ifenslave
net-misc/memcached
net-misc/netdate
net-misc/nstx
net-misc/pcapfix
net-nds/nsscache
net-wireless/bss
net-wireless/spectools
sys-apps/clrngd
sys-apps/input-utils
sys-apps/linux-misc-apps
sys-apps/usbmon
sys-auth/icmpdn
sys-auth/nss_ldap
sys-block/btrace
sys-block/fio
sys-block/scsiping
sys-block/scsirastools
sys-block/seekwatcher
sys-block/tw_cli
sys-power/iasl
sys-power/nut
sys-power/pmtools
sys-process/audit

Items in this list, you're welcome to take them, just leave a note; they will
still work last I checked, and I do use them occasionally, but I'm not fussy
about them.
app-emulation/qenv
app-misc/dnetc
app-misc/interceptty
app-text/binfind
app-text/convmv
dev-cpp/threadpool
dev-db/libdbi
dev-db/libdbi-drivers
dev-lang/snobol
dev-libs/bglibs
dev-libs/OpenSRF
dev-libs/yaz
dev-lua/lgi
dev-util/checkbashisms
dev-util/fuzz
dev-util/idutils
dev-util/its4
dev-util/mpatch
dev-util/pscan
dev-util/rats
dev-util/re2c
dev-util/sgb
dev-util/wiggle
media-gfx/monica
media-gfx/springgraph
net-firewall/ipset
net-libs/cvm
net-misc/dcetest
net-misc/openrdate
net-misc/rdate
net-misc/tiers
net-misc/valve
net-misc/vmnet
net-misc/vmpsd
net-misc/zsync
net-nds/led
net-proxy/piper
sys-apps/hwinfo
sys-libs/openhpi


-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Theo Chatzimichos]

[-- Attachment #1: Type: text/plain, Size: 203 bytes --]

On Wednesday 30 of October 2013 22:10:27 Robin H. Johnson wrote:
> Packages for tree-cleaner consideration:
> dev-vcs/gitosis
> dev-vcs/gitosis-gentoo

Kill them, gitolite is the proper replacement

Theo

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 4697 bytes --]

On 10/30/2013 05:10 PM, Robin H. Johnson wrote:
> Hi all,
> 
> Since it's been nearly a year since I last sent this email (and I got poked
> with a stick about this), it's time for a reminder. I hope that in future, if
> we get a non-maintainer update GLEP [1], this will become unneeded, as it can
> be on api.gentoo.org.
> 
> 1. http://thread.gmane.org/gmane.linux.gentoo.devel/86359
> 
> Over the years, I've come to be the maintainer a huge number of packages (300+)
> Many of them are from inheriting packages when other developers have retired -
> the upstream may also be dead, but there is nothing that supersedes the
> functionality of the package, so if I use it, it lives.
> 
> If you're a developer waiting for an action on one of them, and you've attached
> a fix to a bug, you should mostly feel free to go ahead any just apply your
> patch. If you break it, I'll hunt you down. 
> 
> If you think you want to take over the package instead, or it should go for
> last-rites/tree-cleaners etc; please claim it here or drop me an email; or for
> the last category: just take it and leave a note.
> 
> Notable changes from last year:
> - I'm releasing mogilefs and perlbal.
> - new category of stuff people are welcome to take.
> 
> Exceptions:
> dev-db/mariadb, dev-db/mysql - mysql herd
> sys-libs/db - base-system
> sys-fs/lvm2 - please be careful!
> 
> Packages where I am the upstream, and feature requests probably won't go far
> without large good patches:
> app-admin/diradm
> app-shells/localshell
> sys-apps/readahead-list
> dev-perl/WattsUp-Daemon
> 
> Packages for tree-cleaner consideration:
> dev-vcs/gitosis
> dev-vcs/gitosis-gentoo
> net-mail/vqadmin
> 
> Here's a list of every package where I'm a maintainer and there is no herd
> listed (but their might be other maintainers), and I slightly care about the
> package:
> app-admin/cancd
> app-arch/duff
> app-arch/unadf
> app-backup/mirdir
> app-crypt/af_alg
> app-crypt/gpg-ringmgr
> app-crypt/mhash
> app-misc/ddccontrol
> app-misc/egads
> app-misc/g15composer
> app-misc/g15daemon
> app-misc/g15macro
> app-misc/g15message
> app-misc/g15stats
> app-misc/gcalcli
> app-text/sloccount
> app-text/unrtf
> dev-libs/libg15
> dev-libs/libg15render
> dev-libs/libmcal
> dev-libs/libmelf
> dev-libs/libmemcache
> dev-libs/libmemcached
> dev-python/google-api-python-client
> dev-vcs/cvs2svn
> dev-vcs/git
> net-analyzer/ipaudit
> net-analyzer/ipv6-toolkit
> net-analyzer/poink
> net-analyzer/raddump
> net-analyzer/sslsniff
> net-analyzer/thrulay
> net-dns/ndu
> net-misc/adjtimex
> net-misc/aggregate
> net-misc/aggregate-flim
> net-misc/ifenslave
> net-misc/memcached
> net-misc/netdate
> net-misc/nstx
> net-misc/pcapfix
> net-nds/nsscache
> net-wireless/bss
> net-wireless/spectools
> sys-apps/clrngd
> sys-apps/input-utils
> sys-apps/linux-misc-apps
> sys-apps/usbmon
> sys-auth/icmpdn
> sys-auth/nss_ldap
> sys-block/btrace
> sys-block/fio
> sys-block/scsiping
> sys-block/scsirastools
> sys-block/seekwatcher
> sys-block/tw_cli
> sys-power/iasl
> sys-power/nut
> sys-power/pmtools
> sys-process/audit
> 
> Items in this list, you're welcome to take them, just leave a note; they will
> still work last I checked, and I do use them occasionally, but I'm not fussy
> about them.
> app-emulation/qenv
> app-misc/dnetc
> app-misc/interceptty
> app-text/binfind
> app-text/convmv
> dev-cpp/threadpool
> dev-db/libdbi
> dev-db/libdbi-drivers
> dev-lang/snobol
> dev-libs/bglibs
> dev-libs/OpenSRF
> dev-libs/yaz
> dev-lua/lgi
> dev-util/checkbashisms
> dev-util/fuzz
> dev-util/idutils
> dev-util/its4
> dev-util/mpatch
> dev-util/pscan
> dev-util/rats
> dev-util/re2c
> dev-util/sgb
> dev-util/wiggle
> media-gfx/monica
> media-gfx/springgraph
> net-firewall/ipset
> net-libs/cvm
> net-misc/dcetest
> net-misc/openrdate
> net-misc/rdate
> net-misc/tiers
> net-misc/valve
> net-misc/vmnet
> net-misc/vmpsd
> net-misc/zsync
> net-nds/led
> net-proxy/piper
> sys-apps/hwinfo
> sys-libs/openhpi
> 
> 

dev-libs/libmemcache  #ok
dev-libs/libmemcached #so
dev-vcs/git           #I will need help with this 600+ line ebuild...
net-analyzer/sslsniff #zerochaos seems to have this as well, I can
co-maintain :D
net-misc/ifenslave    #I'll take it
net-misc/memcached    #And this
sys-auth/nss_ldap     #and this
sys-block/fio         #...
sys-power/nut         #wellnow
sys-power/pmtools     #I ran out of things to say

I will be taking these unless someone wants to yell at me (tomorrow or
so).  I welcome all help :P

-- 
-- Matthew Thode (prometheanfire)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Robin H. Johnson]

On Wed, Oct 30, 2013 at 06:27:17PM -0500, Matthew Thode wrote:
> dev-libs/libmemcache  #ok
> dev-libs/libmemcached #so
> dev-vcs/git           #I will need help with this 600+ line ebuild...
On that middle list, I suggest adding yourself, not replacing me.

> net-misc/ifenslave    #I'll take it
Long-term should probably be removed, replaced by sysfs+iproute2; still
useful on embedded for now.

> net-misc/memcached    #And this
> sys-auth/nss_ldap     #and this
You get pam_ldap as well, partial common codebase upstream.

> sys-block/fio         #...
> sys-power/nut         #wellnow
Don't break em ;-).

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Alice Ferrazzi]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

I can help on dev-vcs/git ?
On Oct 31, 2013 8:31 AM, "Robin H. Johnson" <robbat2@gentoo.org> wrote:

> On Wed, Oct 30, 2013 at 06:27:17PM -0500, Matthew Thode wrote:
> > dev-libs/libmemcache  #ok
> > dev-libs/libmemcached #so
> > dev-vcs/git           #I will need help with this 600+ line ebuild...
> On that middle list, I suggest adding yourself, not replacing me.
>
> > net-misc/ifenslave    #I'll take it
> Long-term should probably be removed, replaced by sysfs+iproute2; still
> useful on embedded for now.
>
> > net-misc/memcached    #And this
> > sys-auth/nss_ldap     #and this
> You get pam_ldap as well, partial common codebase upstream.
>
> > sys-block/fio         #...
> > sys-power/nut         #wellnow
> Don't break em ;-).
>
> --
> Robin Hugh Johnson
> Gentoo Linux: Developer, Trustee & Infrastructure Lead
> E-Mail     : robbat2@gentoo.org
> GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
>
>

[-- Attachment #2: Type: text/html, Size: 1319 bytes --]

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> net-analyzer/sslsniff #zerochaos seems to have this as well, I can 
> co-maintain :D
be my guest

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSccFgAAoJEKXdFCfdEflKY3cP/REftlb2J5DTdWNzBFPBB8J8
/QAGTyd+RXro37n3drB544Ofop/UPrMaHHeaMuRFSf58JqNGTW6RZ4Oj7daLrUWV
/lHSpUDUDul0O3pnFbjrQ50ndAArSo1VFtmAlPeGwVAMwORLbr1Ul3oPb7JIODJn
C2gHNwPNUPEYQ4u5wImsCMA1OWOyoLNMGr/GYNgoAk/SeN8ZjVo9zeH2xfO9ckBV
QVgaN48IcsHPi/m0YbY5NhN8oVWVYSTwJLw7hqF14i+CNkYxLOz0at+XvUxgjXFA
5Z/7S5742zBFfzm2vTcEKtROAYiw2QjV2i6BTNByPZHYaGMKZsYP1QQl2dvKJl54
s9bG+eeJ3458IzR4vVexqgfUim3wHueqQfOtU7+/hvuN7PA0S9YYLxnPYk0aCy+w
jO3fJ5tBLOhzTDCyQBSFhhr1Z9kH0H5eWFLuk4H+VYg5wBwHbrgRQKP6zJ5/IhPT
6h4oWsUG80jmnXs6muzc05ma4ce0xLzb0NAoiuFatWSYzkz+3BzpxAMhghLC50fO
8Uzm/hjR4PO6Xs96thY8WiqKLAA2JDVbyiWU4BK4o2/cNW4ozBbGcSrRXMAzRxR9
LI6hNhuvj+SSIwZGoN+6VxBbsZRtIp/cEySuXvLu3tNBXVjy/f0j87hau8QOxpSl
fhlOdQ1mwnX0dkT4RhZf
=T40+
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Lars Wendler]

[-- Attachment #1: Type: text/plain, Size: 4653 bytes --]

Am Wed, 30 Oct 2013 22:10:27 +0000
schrieb "Robin H. Johnson" <robbat2@gentoo.org>:

> Hi all,
> 
> Since it's been nearly a year since I last sent this email (and I got
> poked with a stick about this), it's time for a reminder. I hope that
> in future, if we get a non-maintainer update GLEP [1], this will
> become unneeded, as it can be on api.gentoo.org.
> 
> 1. http://thread.gmane.org/gmane.linux.gentoo.devel/86359
> 
> Over the years, I've come to be the maintainer a huge number of
> packages (300+) Many of them are from inheriting packages when other
> developers have retired - the upstream may also be dead, but there is
> nothing that supersedes the functionality of the package, so if I use
> it, it lives.
> 
> If you're a developer waiting for an action on one of them, and
> you've attached a fix to a bug, you should mostly feel free to go
> ahead any just apply your patch. If you break it, I'll hunt you down. 
> 
> If you think you want to take over the package instead, or it should
> go for last-rites/tree-cleaners etc; please claim it here or drop me
> an email; or for the last category: just take it and leave a note.
> 
> Notable changes from last year:
> - I'm releasing mogilefs and perlbal.
> - new category of stuff people are welcome to take.
> 
> Exceptions:
> dev-db/mariadb, dev-db/mysql - mysql herd
> sys-libs/db - base-system
> sys-fs/lvm2 - please be careful!
> 
> Packages where I am the upstream, and feature requests probably won't
> go far without large good patches:
> app-admin/diradm
> app-shells/localshell
> sys-apps/readahead-list
> dev-perl/WattsUp-Daemon
> 
> Packages for tree-cleaner consideration:
> dev-vcs/gitosis
> dev-vcs/gitosis-gentoo
> net-mail/vqadmin
> 
> Here's a list of every package where I'm a maintainer and there is no
> herd listed (but their might be other maintainers), and I slightly
> care about the package:
> app-admin/cancd
> app-arch/duff
> app-arch/unadf
> app-backup/mirdir
> app-crypt/af_alg
> app-crypt/gpg-ringmgr
> app-crypt/mhash
> app-misc/ddccontrol
> app-misc/egads
> app-misc/g15composer
> app-misc/g15daemon
> app-misc/g15macro
> app-misc/g15message
> app-misc/g15stats
> app-misc/gcalcli
> app-text/sloccount
> app-text/unrtf
> dev-libs/libg15
> dev-libs/libg15render
> dev-libs/libmcal
> dev-libs/libmelf
> dev-libs/libmemcache
> dev-libs/libmemcached
> dev-python/google-api-python-client
> dev-vcs/cvs2svn
> dev-vcs/git
> net-analyzer/ipaudit
> net-analyzer/ipv6-toolkit
> net-analyzer/poink
> net-analyzer/raddump
> net-analyzer/sslsniff
> net-analyzer/thrulay
> net-dns/ndu
> net-misc/adjtimex
> net-misc/aggregate
> net-misc/aggregate-flim
> net-misc/ifenslave
> net-misc/memcached
> net-misc/netdate
> net-misc/nstx
> net-misc/pcapfix
> net-nds/nsscache
> net-wireless/bss
> net-wireless/spectools
> sys-apps/clrngd
> sys-apps/input-utils
> sys-apps/linux-misc-apps
> sys-apps/usbmon
> sys-auth/icmpdn
> sys-auth/nss_ldap
> sys-block/btrace
> sys-block/fio
> sys-block/scsiping
> sys-block/scsirastools
> sys-block/seekwatcher
> sys-block/tw_cli
> sys-power/iasl
> sys-power/nut
> sys-power/pmtools
> sys-process/audit
> 
> Items in this list, you're welcome to take them, just leave a note;
> they will still work last I checked, and I do use them occasionally,
> but I'm not fussy about them.
> app-emulation/qenv
> app-misc/dnetc
> app-misc/interceptty
> app-text/binfind
> app-text/convmv
> dev-cpp/threadpool
> dev-db/libdbi
> dev-db/libdbi-drivers
> dev-lang/snobol
> dev-libs/bglibs
> dev-libs/OpenSRF
> dev-libs/yaz
> dev-lua/lgi
> dev-util/checkbashisms
> dev-util/fuzz
> dev-util/idutils
> dev-util/its4
> dev-util/mpatch
> dev-util/pscan
> dev-util/rats
> dev-util/re2c
> dev-util/sgb
> dev-util/wiggle
> media-gfx/monica
> media-gfx/springgraph
> net-firewall/ipset
> net-libs/cvm
> net-misc/dcetest
> net-misc/openrdate
> net-misc/rdate
> net-misc/tiers
> net-misc/valve
> net-misc/vmnet
> net-misc/vmpsd
> net-misc/zsync
> net-nds/led
> net-proxy/piper
> sys-apps/hwinfo
> sys-libs/openhpi
> 
> 


app-misc/g15composer
app-misc/g15daemon
app-misc/g15macro
app-misc/g15message
app-misc/g15stats
dev-libs/libg15
dev-libs/libg15render

I could help maintaining these as I am using a Logitech G15 and have a
Logitech G19 in my locker.


dev-vcs/git

I'd be interested in this as well although like promethanfire I might
be overwhelmed with the mere amount of code in the ebuilds.


app-text/convmv

I will take it.

-- 
Lars Wendler
Gentoo package maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Robin H. Johnson]

On Thu, Oct 31, 2013 at 10:09:19AM +0100, Lars Wendler wrote:
> app-misc/g15composer
> app-misc/g15daemon
> app-misc/g15macro
> app-misc/g15message
> app-misc/g15stats
> dev-libs/libg15
> dev-libs/libg15render
> I could help maintaining these as I am using a Logitech G15 and have a
> Logitech G19 in my locker.
I've got a G510 here, and recently met the Logitech team responsible for
the product development on these; I'm discussing with them about having
some actual specifications. You're welcome to help co-maintain for now,
I might up end up as upstream instead.

> dev-vcs/git
> I'd be interested in this as well although like promethanfire I might
> be overwhelmed with the mere amount of code in the ebuilds.
Add yourselves to it.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30/10/13 06:10 PM, Robin H. Johnson wrote:
> sys-block/tw_cli

I've got hardware for this one, so I can take it.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlJyWs8ACgkQ2ugaI38ACPDOBQD+ITeE69Q3L0YOD/GkNH13GTsc
L0kyMuo9k3aFcoqJzjEA/3kYpnGfOXq2r99WSQxrn6wTndUsMr0wsRMNHE553iXv
=nyNR
-----END PGP SIGNATURE-----