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

[Nick Vinson]

On 10/07/2016 07:32 AM, Raymond Jennings wrote:
> 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?

You don't and I think that's really being overlooked.  If ComRel screwed
up, then "fixing" the mistake is also reversing their decisions that
includes bringing back the dev.  If the developer is really a problem,
then ComRel will be given repeated chances to deal with the developer
and eventually (well hopefully not eventually) the "due process" will be
done correctly and the developer will be removed.

To me this really seems to follow the line of thinking of "If the dev
was really innocent of any wrong doing, no complaint would have been
filed".  I hope that's not the case because I find that style of logic
to be both naive and dangerous.

-Nicholas Vinson

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