[agl-discussions] Open issues with gerrit and git usage from Agile Albacore

Jan-Simon Möller jsmoeller at linuxfoundation.org
Fri Jan 15 16:58:15 UTC 2016


Hi * !

Thoughts inline ...

Am Freitag, 15. Januar 2016, 10:31:05 schrieb Walt Miner:
> Hi Fulup,
> Great thoughts. First - can you add this as a comment to the Jira issue so
> we do not lose it. I added some thoughts in-line.
> > 
> > I think AGL would benefit from a shared space for components we are
> > developing. Obviously we may continue to use github or any other public
> > repository. Nevertheless as said before I doubt this is the best option to
> > provide visibility to AGL. Technically it should not be too complex to
> > create a dedicated space for "in-dev" AGL components. I think that within
> > 
> > those repos:
> >  - every AGL member should have the right to propose a patch, report a
> > 
> > bug, etc.
> > 
> >  - in order to limit load on AGL technical staff, repo maintenance like
> > 
> > accept/deny of patches, creation of sub-repositories, branches management,
> > etc. should be delegate to maintainers of corresponding component.
> > 
> <Walt> Two separate issues here. First there is the case we had with MOST
> driver where there is something getting back ported or added to project. We
> need somewhere in AGL for that.
> 
> For the second topic (creating an in-dev space), this is basically what we
> did for the demo apps. Anyone with access could push to the master without
> a review. We could create  something like a Prototype repo with directories
> for different proposals and add people as requested per project.

+1 for the shared space. We can easily set up a /STAGING container in gerrit 
with relaxed ACLs - e.g. where self-approving your code or direct pushes are 
possible for logged-in users. 

We have to check if we can delegate the repo creation - @Walt ?

 
> > Note: I do not think pushing something on those "in-dev" repositories
> > should go through Gerrit. Pushing a proposal should be very light. Any
> > member from AGL should be able to propose something and a simple OK from
> > one of the maintainer should be enough to accept the merge. On the other
> > hand review process through Jira for patches on meta/layer should be kept
> > identical as today for both external and internal to AGL repositories.
> 
> <Walt> I think you meant gerrit and not Jira in the last sentence. Like I
> said above we had a simplified review process for demo apps that we can
> adapt any prototype projects. I would prefer to keep in gerrit with a
> simplified process for now.

See above. Question is how we add those repos to the CI builds this will be
case-by-case then for now. 

 
> > Fulup
> > 
> > On 14/01/16 00:58, Walt Miner wrote:
> >> I want to collect the open issues with git and gerrit usage we had
> >> during the final month of integration for the Agile Albacore release.
> >> Going through my notes we had:
> >> 
> >> 1) We need to settle on how we will manage kernel patches such as the
> >> MOST USB driver that was back ported from kernel 4.3 to AGL by
> >> Christian. We temporarily put it in meta-agl-demo but we need a place to
> >> put these types of changes  I created Jira issue SPEC-92 [1] for this.
> >> We need a general solution that applies to code changes made to packages
> >> that currently only exist in meta layers.

The MOST driver is now relatively easy if we do it in the 
"kernel module out-of-tree" (much like dkms) way. It can be a separate 
package. Tricky part is the multi-kernel-version support in the recipe.

> >> 2) Now that we have an albacore branch we need a way to identify patches
> >> to be merged to that branch as we continue on Master for Brilliant
> >> Blowfish. We probably need a maintainer identified for Albacore. For now
> >> I assume it is Jan-Simon and any patches to be merged to Albacore will
> >> need to be sent through him in gerrit for review.

- Patches should be backports from master or derived from master. 
- Patches cann be flagged with [master][albacore] if they should go into 
  multiple branches. 
- Submission of patches is possible to the albacore if you branch of 
  gerrit/albacore and call git review from there
  (see the .gitreview file in the albacore branch)
  e.g.
  git remote update
  git branch topic-for-albacore
  git checkout topic-for-albacore
  git reset --hard gerrit/albacore
  # change code, stage, commit
  # git review [OPTIONS] ... [BRANCH]
  # [BRANCH] is optional as we set defaultbranch to albacore in .gitreview
  git review



Best,
Jan-Simon


More information about the automotive-discussions mailing list