Re: [gentoo-project] Re: Trying to become a Gentoo Developer again spanning 8 years...

[Raymond Jennings]

On Fri, Oct 7, 2016 at 7:20 AM, Rich Freeman <rich0@g.o> wrote:
> On Fri, Oct 7, 2016 at 10:05 AM, Raymond Jennings
> <shentino@×××××.com> wrote:
>>  My opinion is that if a developer is bad enough to keep out, its
>> also
>>  important enough to get the paperwork fixed to prove it.  If they
>> have a
>>  clean case it *should* be very easy to get the paperwork right.
>
> Sure, by all means leave the bug open until the paperwork is fixed,
> but I don't think that means that the developer should be allowed back
> in if the bug isn't closed before some deadline.

What I want to prevent is a stagnation where a dev gets mistakenly 
locked out because his case got left in limbo.

>>  But its the "due process" here that proves the developer is bad to
>> begin
>>  with.  If comrel screwed up and there was a mistake and the
>> developer is
>>  actually meritorious, its bad for gentoo to keep them out.

> Sure, if all three of your preconditions are true I agree with your
> conclusion.  However, if comrel screwed up and there was a mistake and
> the developer is actually still a problem, then the solution is to fix
> the mistakes, not keep them around.

And how do you know whether the developer is a problem or not?

>>  Also, I just realized that the "everyone votes" blocks comrel
>> manpower from
>>  scaling.
>>
>>  What if each member of comrel was granted the discretion to handle
>>  everything as they themselves saw fit, subject to the provision
>> that the
>>  comrel lead/comrel as a group/the council could receive appeals?
>
> I tend to agree with this, or a process where Comrel assigns a small
> group of devs to each case.  The Comrel lead or maybe the entirety of
> Comrel could keep a general eye on things as a level of QA and there
> would still be Council appeals.  I've heard the issue raised that the
> system where all of Comrel deals with every case also causes issues
> when some members of Comrel aren't around or don't have time to deal
> with every case.  Basically it makes all of Comrel as fast as its
> slowest member.  Imagine if every stablereq required every member of
> an arch team to approve it?  It would be like Ago trying to swim with
> concrete shoes.

And this is exactly why I suggest breaking comrel up into a team of 
independent agents overseen by guidelines that preserve uniformity.

Being geeks we are all probably familiar with the benefits of 
parallelization.  It's like

# make comrel -jN

:)

And that means comrel shouldn't be drowning in its own red tape.

> Indeed, with the model where all Comrel members deciding every case
> recruiting more manpower to Comrel would actually have the ironic
> effect of lowering their productivity.  The best thing you could do in
> such a model is instead boot out the slowest contributors.
>
>>>  Imagine if stale stablereqs could be appealed
>>>  to Council...  :)
>>
>>  Maybe not stale stablereqs themselves.  This is a volunteer project
>> with
>>  finite manpower.
>>
>>  However, someone deliberately *ignoring* a stablereq when there's a
>> large
>>  need for it MIGHT be more worthy of an escalation.  But merely being
>>  overworked should not be an offense, and it would probably go
>> through comrel
>>  first.
>
> If you punish people for ignoring important bugs at times, then you
> just encourage people to not sign up for the job in the first place.
> If you have a single queue multiple server model (which is how most
> projects tend to work, including arch teams), then the queue only
> stalls if all the servers stall.  The solution in this case isn't to
> kick out servers, but rather to encourage more to show up and deal
> with the high priority bugs (the reality is that our servers don't
> strictly work on bugs in priority order, though again I think that
> trying to change this could actually lower throughput).  Even if a
> server only closes one bug per year, that still has a net positive
> impact on the queue (assuming zero overhead, which is mostly true for
> the way we work).

My point is that going after people for deliberately ignoring stablereq 
is *less* stupid than spamming council with appeals on stale stablereq.

I never said it was a good idea, just less bad.

The proper solution would probably be an algorithm that flags the most 
urgent stablereq's.

stablereq triage score = age in days * number of reverse deps blocked 
on the stablereq

Google lives and breathes and eats algorithms, and they even use gentoo 
devs as a recruiting ground (hello recruiters!).
> --
> Rich
>