[apparmor] [RFC] test git tree for the apparmor-profiles repo

[Steve Beattie]

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
> tree.

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 [0] 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
bzr tree.

> > 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.
http://blog.timmattison.com/archives/2011/06/13/how-to-convert-from-bzr-to-git-on-debianubuntu/
) 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
https://www.fusonic.net/en/blog/migrating-from-bazaar-to-git/ during
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.)

[0] in debian versioning, ~ indicates before, so e.g. 2.10 > 2.10~rc1

-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20160223/b2dd4f52/attachment.pgp>