[agl-discussions] [RFC] Development / Gerrit Workflow tuning

José Bollo jose.bollo at iot.bzh
Fri Feb 16 09:55:11 UTC 2018


On Wed, 07 Feb 2018 16:07:57 +0100
Jan-Simon Möller <jsmoeller at linuxfoundation.org> wrote:

> Hi all !
> 
> As a follow-up of today's SAT call we'd like to gather your feedback
> about the current gerrit workflow and how we can improve it.
> 
> Please reply with your thoughts:
> - what is working good and should be kept as-is ?
> - what is slowing us down ?
> - what else would you change ?

I'd like to share some concern about the use of SRCREV and AUTOREV.

I'm understanding that some of us would like to lighten developers (or
integrators) load by making the yocto meta-layers of AGL using the
AUTOREV feature (that's the idea but in the facts it is subtly more
complicated). They argue that developers will only review source code
that will automatically enter the distribution without a second review
for the recipe.

I got issues with this model.

When working on bump to rocko, it was not obvious to know clearly the
reason of problems. It is more a theoretical issue that a real one
but... How to be sure that the system adjustment are valid when at the
same time applications may change? It clearly asks the question of
distinguishing the work flows: the system flow and the application flow.

I'm working on a component of AGL that requires forward work,
test and, sometime, revert on impasse. This can be reviewed and I can
use sandbox for testing. But I really appreciate to separate this
development process from how and when AGL distribution bumps to use
latest available and tested version.

Yesterday, I worked on an issue related to session close on time update
(SPEC-1296). I made a change for EEL. I pushed it on branch EEL but,
unfortunately, made no review. So the patch entered, de facto, in EEL
but:
 - how to make a new image that get in download.automotive.org now?
 - how to clearly see that a EEL image has or not the fix?

I wrote in penultimate paragraph that my work can be reviewed. I
confirm it. But honestly, I'm busy and have no much time to get in
review of other projects. I trust my fellow developers to do their best
all the time. However, I am interested in knowing when they submit a
newer version, what are the new features and bug fixes. I think that
a specific review that changes PV and/or SRCREV fits well this
interest and in the same time put the history of AGL in the git layers
of AGL.

For all of these reason, I'd like to avoid use of AUTOREV, AGL_BRANCH
or AGL_APP_REVISION.

My 2c

Best regards
José Bollo

> For the next development cycle, we'd like to gather your feedback on
> the proposed adaptations for the gerrit process:
> 
> - We want to increase the number of maintainers with merge access to
>   avoid bottlenecks and speed-up the flow of code.
> - Each profile (IVI, telematics, core) would have a set of
> maintainers (>=3)
> - src / staging would have a set of maintainers (>=5) 
> - Maintainers would be nominated by the community and approved by SAT
> - Maintainers get +2 and merge rights in gerrit
> - gerrit will be adapted to:
> -- ignore the vote of the submitter/owner of the patch (no vote on
> own patch) -- votes become additive  (e.g.  +2 & +2 = +4)
>    --- e.g. a +4 is required for merge  
>    --- up for discussion 
>        --- if +2  [=1*+2 merger review or as option 2*+1 normal
> reviews] --- or +4 [= 2*+2 merger review or as option 4*+1 normal
> reviews] -- all src / staging repos need to go through gerrit reviews
> going forward (no more direct push)
> 
> 
> Please tell us your thoughts about the above questions and the
> proposal.
> 
> 
> Thanks.
> 
> Best regards,
> 
> Jan-Simon Möller
> AGL Release Manager
> 
> _______________________________________________
> automotive-discussions mailing list
> automotive-discussions at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions



More information about the automotive-discussions mailing list