[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