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

[Markos Chandras]

On Sun, Aug 08, 2010 at 11:06:51AM +0000, Jorge Manuel B. S. Vicetto wrote:
> >>
> > 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.
I really really really doubt that most of our projects run yearly elections.
Instead of having one person following every project status updates, make the
project leads sending reports to e.g. gentoo-project ML about status updates.
Something like [Qt project]: 4 active, 15 inactive members, elections two
months ago, we need more manpower is sufficient. Posting such reports on
public ML will help users to track down project needs and step up and help if
needed. If we have enough manpower we can have a global page as well
> 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.
Sure but you need to give this project powerzzzz to smash down any project
that fails to report its status as well. 
>
> > 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
Really? I am pretty sure that there are quite a lot of people out there that
want to help but they simply can't get in touch with slow ( lets don't say
"dear" ) projects. Just look at the bugs of these projects. There are tons of
patches attached but projects don't give a shit.
> 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".
This is not about labeling. This is about reality. If a project is really
dead, remove it from the list, assign the bugs to maintainer-needed and let
everybody know that there is really nobody looking after these packages. 

I think users prefer a smaller ( ebuild number wise ) but more active project than a big and slow
one.

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410