-----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-----
