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

Fri Feb 16 11:48:56 UTC 2018

Hi

I understood your concern. I agree with Jose.

And I have a concern of the version.

I'd like to know there is a rule for the version of recipe.

The recipes developed in AGL are normally named as "XXXX_git.bb".
I'm understanding "git" is useful for people to use the latest code.

I'd like to know we can choose to set version such like "XXXX_1.0.bb".

When the code is changed largely in sandbox for example and want to merge,
other people can't know the major change only with SRCREV.
I think using version is useful to notify people of major or minor change.

In my opinion, if there is no change of interface or behavior, the 
change of SRCREV hash is enough.
If there are some changes of interface or behavior, it's thankful for 
people to know the change.

Best Regards
  Kazumasa Mitsunari

On 2018/02/16 18:55, José Bollo wrote:
> 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
> _______________________________________________
> automotive-discussions mailing list
> automotive-discussions at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions

-- 
*******************************
WITZ Corporation
    基盤技術開発部 応用基盤技術室
    Base Technology Development Dept.
  　Advanced Basic Technology Sect.
  　Kazumasa Mitsunari
  Mail:knimitz at witz-inc.co.jp
  TEL:06-6451-2017
*******************************