El jue, 03-06-2010 a las 13:36 +0300, Samuli Suominen escribió:
> For the record, media-optical herd is currently without any devs and
> also the mail alias in d.g.o is empty so nobody is really reading the
> bugmail.
>
> In case you want to join it...
>
> - Samuli

Would be possible to modify script that generates
http://www.gentoo.org/proj/en/metastructure/herds/herds.xml to list
empty herds on a different section at the top of the webpage for
detecting herds without people easier?

Even better would be to also provide information about "devway"
developers, indicating something like, for example:
41. gnome
- Description
GNOME Desktop and related packages
- Herd maintainers' email address
gnome@gentoo.org
- Maintainers
...
pacho@gentoo.org (Pacho Ramos) (Devway)

But I am not sure if it would be possible :-/

Also, maybe we should consider change the assignment for bugs assigned
to empty herds, assigning them to maintainers-needed and CCing affected
herd, that way, once somebody revives the herd, he could simply revert
the assign to the old way and, until then, people reviewing
maintainers-needed bugs would also notice that bug reports.

Thanks a lot

On 6/3/10 3:32 PM, Markos Chandras wrote:
> And maybe it would be a wise move to merge/remove some herds because ,as I
> see, the number of herds is equal ( or even higher ) to the number of
> developers.

Here are some more empty herds:

1) kerberos herd is empty
2) secure-tunnelling is empty
3) utf8 is empty and looks like a candidate for removal

As for other herds, I don't see anything obviously wrong. It seems fine
and useful to have a generic alias even if there is only one developer
in a herd.

Paweł

On Thursday, June 03, 2010 10:44:10 am Markos Chandras wrote:
> kernel can merge with kernel-misc.

Please don't do this.

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

On 03-06-2010 14:44, Markos Chandras wrote:
> all the gnome-* herds look obsolete to me. It should be like kde and use
> only one alias. Further more the comm-fax could be merged with a net-*
> alias, and all the desktop-* could be merged in one herd.

The desktop-effects herd has nothing to do with any of the other desktop
herds, so they shouldn't be merged.
Just because you don't understand why an herd exists or it looks
"obsolete" to you, it doesn't mean it doesn't have a meaning for the
people on the herd.

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMB9kQAAoJEC8ZTXQF1qEPIZ8P/RCcVS6XlgKzLeq9bguRzDjf
Fy/Ggvi8CnqSi8GWUPsjr+tFq76eBdHrLqp6bGxbENDFfblC8fn/hrjcHQGdRztm
N7RjAzS4SzVmD3YSH0HFe1+2wgyTAoLfVGT/KYGdmeKwp9RzDtS2NkHSM0ftfV+y
TT3KnJI13pUIdJRY+GGCiodzZFOUZKeqrCiO2p8jbw06MzsNWD zGoPI6wvsB54mM
164tYV1OEWvTCdaUF8E7oImLle43FHfYuY5D/Oda6QqvMI6f01mlSyls+IWHHBL5
6anc91fex9fd71dMULVWA66pWqpuFywfZxUHDqdn9jWEdFJgV8 zn6NRxxVuyg4Hd
HTGjcajxP7DwH4FX7LplrEExOnFdO1Qxs1bqvwIIajsXiv0EPw dL1+Uhgn/7FV0K
HF/WMyikIAybILG1LaOnGgQElqLQ+irRB0GQ7mn71XVlIioU9cWGT rSRpT/0fdXq
NH4ZgJER8sKWT0KQlxsmBCj8oMoR5xhEK7FqbjjMXodPu76yJQ z8Y+5sBdUc9bh3
mW9aDffQdZoklfCNc+0O2xg3DVt7QQJV2Gp0/vcNt5Ivb76W3WZQYBfOI7HIQPAq
QBCg4nLe5cmZoabNCZ3Y3QuUQLAJSyqGl7XxVP/i9QNdzN+EBNKJa/lPQWRceiQV
UaGTOvoo1S16OXjBFRa8
=z723
-----END PGP SIGNATURE-----

On Thu, 3 Jun 2010 17:44:10 +0300
Markos Chandras <hwoarang@gentoo.org> wrote:

> all the gnome-* herds look obsolete to me. It should be like kde and
> use only one alias. Further more the comm-fax could be merged with a
> net-* alias, and all the desktop-* could be merged in one herd. The
> dev-embedded could be merged with embedded, kernel can merge with
> kernel-misc. Plus I am sure that we can perform a clean up/merge on
> net-* herds. Same rule for sci-*.

Speaking for myself, the net-* and netmon herds are much too diverse to
pile onto one big stack. As with the other suggested herd mergers, you'd
merely end up piling more work onto unsuspecting developers' desktops,
possibly discouraging some of them to dig through all the extra
incoming mail. If any changes are made in this respect, it should have
the approval of all members of all herds considered for a merger.

> Having 150 herds for 300 *listed* devs doesn't seem optimal

You could qualify that statement a lot better. I don't see a problem
here. Many developers are members of more than one herd, which the
simple 2:1 relation you exemplify does not carry out that important bit
of information.

There is a real problem with herds that have a single or no
maintainer, the former mainly because that could very well lead to
another case of the latter, and we should certainly address both
problems, but we should create as little as possible new problems in
the process.


Regards,
jer

On Thu, Jun 03, 2010 at 04:28:57PM +0200, "Paweł Hajdan, Jr." wrote:
> 1) kerberos herd is empty

FWIW, I proxy maintain app-crypt/heimdal, app-crypt/mit-krb5,
app-crypt/mit-krb5-appl and sys-auth/pam_krb5. Thanks to darkside and
flameeyes for their help.

--
Eray

On Thu, 3 Jun 2010 22:35:04 +0200
Ben de Groot <yngwin@gentoo.org> wrote:

> Also, there are herds that have several members, but none of them is
> really active (games, most of the desktop-* herds, etc.). This also
> leads to users being discouraged because the bugs they file are left
> ignored.
>
> This needs a structural solution. I think we need a team to
> systematically look at open bugs and to notify the community of such
> problematic herds. I imagine this would be a QA subproject.

That would basically be a task other than bug-wranglers, but jakub used
to do all this and I do it sometimes, among a few others who either
just scratch an itch or take a general interest. Maybe the
bug-wranglers project can be extended since it at least has some active
people (not just developers), but as it now stands there are again 150
unassigned bugs after only a week (up from ~40 since the last
reassignment run I believe).

"Calling in" QA as such usually isn't really beneficial.

> Then we also need some structure to redirect some dev love to these
> problematic areas. We need to advertise these needs more, to get
> trusted users to proxy-maintain. We need to streamline the recruitment
> process to make it easier for people who want to volunteer to become
> devs. And I could go on for a while. There are a lot of areas where
> Gentoo has a lot of room for improvement, and they all interlock.

All these problems seem to come down to the fact that we're
understaffed in most departments.

Setting up yet another project isn't going to help much. Just looking
at open bugs (bugzilla can help you figure out which bugs might need
someone's particular attention). What might help right now is look at
the herds.xml data and combining that with activity rates of the
developers in all herds. Herds with few developers and lots of open
bugs is something you could calculate and filter down into a monthly or
weekly report you send to a mailing list (probably dev-announce?).

> I believe we need to formulate a vision of what we want Gentoo to be,
> and then develop strategies of how to get there. Having a team that
> systematically looks at the state of herds as well as open bugs is
> --in my opinion-- a crucial first step to adress some of the
> structural problems that have plagued Gentoo for years.

Do you mean we should redefine what Gentoo is about, to satisfy the lack
of active developers? Bring down the number of packages? Or address the
staff shortage? That last one is rather old, as recruiters have been
clamouring for help for years now.


Regards,
jer