[apparmor] [RFC] test git tree for the apparmor-profiles repo
steve at nxnw.org
Tue Feb 23 19:14:22 UTC 2016
On Mon, Feb 22, 2016 at 06:10:25PM -0600, Tyler Hicks wrote:
> On 2016-02-22 09:53:50, Steve Beattie wrote:
> > I've created a test git repo of the apparmor-profiles tree at
> > https://code.launchpad.net/~sbeattie/+git/apparmor-profiles-test
> > based on a simple conversion of the bzr tree. The origin tree is pretty
> > simple, we don't have any long term branches and it doesn't look like
> > any used the --fixes bzr argument to annotate commits as fixing any
> > specific bugs. Please poke at this tree (particularly those of you
> > who have a clue what they're doing with git, unlike myself) to see
> > if there's anything odd or messed up with the conversion or history.
> While I haven't dealt with the apparmor-profiles tree much, this git
> tree looks good.
Thanks for the feedback. I note that Kshtij didn't raise any issues
with the history on IRC. I'd like other people's positive or negative
feedback before promoting it as the official repo.
> It is also worth noting that there were no bzr tags used in
> lp:apparmor-profiles so, obviously, there are no git tags in the test
Yep. That's another wrinkle when dealing with converting the
main apparmor tree; git doesn't support tags with '~' in them,
while bzr supports them. We used '~' in a version/tag  once,
for apparmor_2.6.0~rc1, which git complains about on fast-import. We
stopped using them precisely because it broke John's git view of the
> > Converting the main apparmor tree will be more difficult in that we
> > have multiple long term branches and we have made more use of the bug
> > fixed annotations. It's also unclear to me if launchpad's translation
> > service understands git repos. In any event, I'll try to get a test
> > git repo up soon.
> By "long term branches" of lp:apparmor, are you talking about
> lp:apparmor/2.9 and lp:apparmor/2.10? If so, I think that'll be somewhat
> easy to handle in a single git repo (with v2.9 and v2.10 branches).
> We'll just want to make sure that we share as many objects as possible
> with those branches and master. That'll probably mean getting the master
> branch all fixed up and then branching off of master at the appropriate
> points in master's history to create v2.9 and v2.10 and then pulling in
> the newer commits to those branches.
Yes, that's what I was referring to, and that's how I'm hoping to
organize things. I don't know how well the available conversion
tools handle doing that, though reading through various blogs (e.g.
) makes me hope that it'll just work. Test attempts seem to indicate
that this is the case.
> As for the bug fixed annotations, I think the best that we can do is to
> identify the commits that have a bug fixed annotation but do not include
> a link to the bug in the commit message body. Those commit messages
> should be modified to include a proper bug report link. (Note that since
> this will require rebasing, this commit message fixup needs to happen
> before the v2.9 and v2.10 branches are created.)
Ugh. I'm hoping to avoid rebasing by doing something like
the import process. But we'll see.
> > Any feedback or advice is welcome. Thanks!
> Nice job! What conversion tool did you end up using?
For this tree, I used bzr fast-export | git fast-import. Sadly, I had
to do it on an Ubuntu 14.04 host, as bzr-fastexport has been dropped
from both debian and 16.04, due to RC bugs and a lack of support. :(
So I'm not sure how much I want to rely on it for more complex things.
(I poked a bit at reposurgeon, too, but it sure looked like it was
trying to treat the bzr tree as a subversion tree, despite my efforts
to inform it otherwise.)
 in debian versioning, ~ indicates before, so e.g. 2.10 > 2.10~rc1
<sbeattie at ubuntu.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the AppArmor