Re: [gentoo-dev] net-proxy/squid needs your love

[Jorge Manuel B. S. Vicetto]

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

On 06-08-2010 22:54, Markos Chandras wrote:
> On Wed, Aug 04, 2010 at 08:47:36PM +0300, Petteri Räty wrote:
>> On 08/04/2010 08:34 PM, Markos Chandras wrote:
>>> On Wed, Aug 04, 2010 at 07:12:18PM +0300, Petteri Räty wrote:
>>>> On 08/04/2010 02:50 PM, Markos Chandras wrote:
>>>>
>>>>>
>>>>> @Council: Yet another example that we need to track the status of every
>>>>> single project in order to have a clear picture of which projects are
>>>>> active and which are dead
>>>>>
>>>>
>>>> Pruning projects that don't actively elect a lead would be a good start
>>>> and that doesn't require anything from the council to be implemented.
>>>>
>>>> Regards,
>>>> Petteri
>>>>
>>> Don't you think we need a team for that? Who is eligible to filter the project
>>> list and ask status updates from them?
>>>
>>
>> I think undertakers can take care of any possible cleanup commits as
>> they already touch project pages for developer retirements.
> Is there enough manpower for that ?

I've been meaning to raise this issue again in the council.
At one point in time, around 4 years ago, a GentooStatus project was
created under User Relations[1]. That project didn't last too long.
Before and after that, a few developers have raised questions about this
issue, some even started a few "What do we <herd|project> do?" threads
now and again and the issue was brought to a few council meetings.
Getting to the point of who is or should be responsible for this issue,
I'd like to point everyone to a little project that seems to have been
forgotten - "metastructure". I've thought before on joining that project
as it seems the natural place to track the status of our projects and it
doesn't seem to be active any longer.
Addressing the suggestion to move this to undertakers, we could run the
scripts to clean the project pages and update the metadata, but we
neither have enough people nor are we "entitled" to go around poking
herds and projects about their status.
In the past, one objection that was constantly raised about mandatory
period updates was that someone could just set up a cron job for it.

>> If you want
>> to join for that purpose just be in contact with them and I think they
>> will accept my proposal.
> I wish I could but I am involved in way too many projects. Maybe on September.
>> As for just status queries I think anyone could
>> query the status from projects and nothing special is required. Of
>> course we should coordinate so that many simultaneous queries are not done.
>>
>> Regards,
>> Petteri
>>
> The inactivity of many herds most of the time blocks the work of some other
> herds. Isn't council's responsibility to step up and resolve these
> interproject issues? It shouldn't be that difficult to ask for monthly project
> status updates ( A simple "Yes, we are alive but slow kthxbye" would be
> sufficient, just to know that somebody is actually listening to that e-mail
> alias after all ), discuss this on Council's monthly meetings ( Shouldn't it take
> more than 20' if you already have the status updates on your Inbox ) and decide whether
> you should prune these herds or not. IMHO undertakers cannot handle the load
> atm but council can.

The issue to me is not council inquiring about projects / herds status,
but the aftermath of that. Some people argue that the council should be
able to close projects and or reform our structure. I don't like that
for the reasons I've stated on my manifesto.
About the montly updates check my above note about the cron jobs.
One thing that has been raised and I think we can already do, is to have
someone (who? - I'd suggest a reformed metastructure project) follow the
yearly projects elections and report them on a global page about teams
and leads. Another option would be to have the elections team publish
all results under its project space.
As GLEP39 already mandates on its specification[4] that all projects
"must occur at least once every 12 months", we can have the
metastructure project report any cases where that doesn't happen to the
dev ml. What should happen after that is something I think the project
needs to address. I'd prefer to have it done in the reform of GLEP39
process.

> Furthermore this inactivity ( as I said before ) doesn't look that good at all
> to our user community . Moreover it seems like dead herds don't even
> bother to ask for help or "hire" more proxy maintainers to co-maintainer some
> of their ebuilds. They just stay quiet on their corner and do nothing. Since
> Council is supposed to be the leading entity of Gentoo I was wondering how
> come this issue never popped up on any of your meetings. Do you really don't
> see a problem here or I am just that weird and everything is running smoothly?

This has been raised on previous council meetings, as far as I can
remember not recently, though.
I agree Gentoo has a problem with dead teams, but I don't think this
problem can be fixed "by decree". Either we can get new people
interested in a team or if possible we may have to drop it, but I
believe a team status won't change just because council labels it as
"moribund" or "dead".

 [1] - http://www.gentoo.org/proj/en/userrel/gentoostatus/
 [2] - http://www.gentoo.org/proj/en/metastructure/
 [3] - http://www.gentoo.org/proj/en/glep/glep-0039.html
 [4] - http://www.gentoo.org/proj/en/glep/glep-0039.html#specification

- -- 
Regards,

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

iQIcBAEBAgAGBQJMXo/LAAoJEC8ZTXQF1qEPuY0P/0Im61ayyuqtkdjbzidUJA4c
djcIyqsRL5xrfNZ/PgbfpGKbnputf7sRzQeCtLtD0mDT7YXZYiqoqSZonQpTT3H/
i0HmhVdYx3gedc3C/MTyzKaL2OLFnSeCYy2wF2WCiFCQr7MkGoMBajrM3AEALOdh
7fLk4grrauACPIT0F65Od2inwHREvKjIKKm/n69nqPTLE7dnLIdQSAhH8C7Vp4Ye
0mNVO8Kq4uTOXDO8cNV006MLbSyIfKSqJLklZts7z2W4uVS8ZjKE292ZIWQi4+W+
0USUi75SjwNT5OyDrDvhaKA7sVQy/UyL+sMntiB8d2g5KjNp7+CwGYDazCCwyeqA
QGq3yEjfqwehUWwQxxTixNqSzABZgaREMR/yhYc/L+U32b+TWmpO6KZDq+dUa4U5
WlKUHIcrVTqkonXVL1m9+S6mqr1v+H0EzEGLU3l7X+wk1y7y4kEDELiWEVByuJ1W
YBkKIUvKfdKiN0tXQEMmj5pNCNIMo+y5c4dlsnUsYGyf/DPTb+vcJ929FhCBs9JA
4oezBvoqJIdUxACFQdZfc2nsXc+i0tfRdOuaPKkXUyuRZgY4n5MDh2YU2/dLq0yk
BOpNt9/sCdtNPQTEfJ1KwR7BECYxaQKWz2vlnQi7sPesbfSmQE6R61Gz8NuYuCoh
zovfiIZS4f2GI5rzt4NT
=y6Ra
-----END PGP SIGNATURE-----