[Dev] State of Pending changes , how to enhance workflow ? ( Was Dear Maintainers )

Patrick Ohly patrick.ohly at intel.com
Tue Feb 4 13:43:28 GMT 2014

Hello all!

Before I comment below, let me point to a common methodology in project
management that helps identify gaps: the RACI-matrix

We are currently debating two task:
     1. code reviews (gerrit)
     2. integration (gbs submit)

For every single project in gerrit, we need to know:
     A. Who is responsible for doing these tasks?
     B. Who is accountable if it doesn't happen?

This is where we have gaps. For integration, we know that maintainers or
(if they were assigned) integrators do it. But who is accountable for
packages which have neither, or for maintainers/integrators who are

Thiago volunteered to handle escalation when a known person becomes
unresponsive. Thiago, will you also take care of the other case
(packages without maintainer or integrator)?

Regarding review the situation is worse. Responsibility has been
assigned to everyone, with the result that no-one feels responsible (I'm
exaggerating, but I guess you get the point). Accountability is
completely unclear.

In the RACI-matrix there are optional roles which are not absolutely
     I. Who needs/wants to be informed?
    II. Consulting regarding technical problems related to a task.

Our tools support for letting people choose what they want to be
informed about is probably not as good as it could be, but that is not a
problem unless it interferes with the required work. In the case of
Gerrit notifications, we erred on the side of informing all potential
reviewers, with the result that developers get too much mail and can't
rely on these notifications to find those reviews that they really need
(and want) to do. This needs to be fixed.

For consulting, we have the domain architects and/or this list. This is
described as a technical role, so architects should not be held
accountable for the smooth operation of the domain (which would be a
management task).

With that in mind, let's look for solutions...

On Mon, 2014-02-03 at 11:32 -0800, Thiago Macieira wrote:
> But I'm not convinced the tool is the problem. There are lots of projects out 
> there using Gerrit efficiently, including Android (for which the tool was 
> created). So maybe the problem is not the tool, just how we're using it, or 
> possibly the workflow we've defined.
> I personally think we have two problems with our use of Gerrit:
> 1) we add too many people automatically to the submissions.


>  If we can't limit 
> it to 3 people, we should add no one.

I propose that we use git/meta/git-trees file to maintain the default
set of reviewers for each project. The maintainer of the project is
already responsible for it, so perhaps we can make him or her
accountable for the review process, which includes having enough
reviewers assigned?

We also need an escalation mechanism for maintainers who cannot find
enough reviewers. Ultimately, it is the companies behind Tizen who are
responsible for assigning enough engineers if volunteers cannot be

> Let the submitter find out who to add by 
> doing git log or checking wiki pages.

This makes the developer accountable for things that he has little to no
control over. I don't think we should do that. As an interim solution it
may work.

> 2) restricting the submission to the maintainer or integrator causes a 
> bottleneck. Well, we created the position of integrator so that it wouldn't 
> bottleneck, so it seems we don't have enough integrators.
> On the first case, it's simple: remove the script that we added that causes so 
> many people to be Cc'ed.

Yes, let's do that as a first step as soon as possible. The next step
then needs to be to set up a reasonable set of default reviewers.

>  On the second, it's a matter of discipline: it's the 
> maintainer job to ensure things get submitted. Conversely, things not getting 
> submitted means the maintainer is not doing his/her job and we should 
> investigate.


Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

More information about the Dev mailing list