Progress update on the tarmac-for-git effort

Paul Larson paul.larson at canonical.com
Fri Jun 5 18:31:07 UTC 2015


Neat! It seems like a good opportunity to split off onto a tarmac-git fork
rather than try to carry the baggage of bzr support. Especially since
tarmac works perfectly fine on bzr branches today, and ny branches that
need tarmac on bzr could easily still run their bzr projects off it. If
someone really needs hooks AND wants to move to git, they may be willing to
help implement it. :)

On Fri, Jun 5, 2015 at 1:15 PM, Zygmunt Krynicki <
zygmunt.krynicki at canonical.com> wrote:

> Hi
>
> As some of you know, I'm working on the git transition for all
> checkbox-related projects. The last blocking element is tarmac, which
> merges our approved bzr branches. Today I wrote a script that can
> process merge requests on both bzr and git branches [1].
>
> The script works against current production instance of launchpad.net
> though I will be making important changes next week when multiple bug
> fixes and new features are released and can be relied upon.
>
> One URL parsing bug aside, (breaks when / are in branch names) it
> generally works. I've used it for a few toy examples today. It is
> terribly unoptimized (doesn't reuse repositories between runs) and it
> doesn't add comments on anything yet but that all is coming. The big
> question, one that we need to answer, is how to proceed with
> development.
>
> There are two possible options:
>  - patch tarmac to support git, perhaps breaking some things (see below)
>    - or bump major version and drop support for python hooks
>  - create a new project by iterating on this prototype
>
> Unknown number of people and projects rely on tarmac today. For them
> it would be very useful to have a drop-in replacement. Tarmac however
> is heavily tied to bzr, both at the implementation of the actual
> operations (it relies on python 2.7 api of bzrlib), command line (all
> command line stuff is inheriting bzrlib classes), configuration and
> hook design.
>
> This has some undesirable properties (python2.7 and bzr are required,
> even if all you use is git). In my quick, hasty opinion tarmac should
> be scrapped as a code-base and recycled as a project with different
> implementation.
>
> For most of our users, this would not be a direct problem as long as
> existing configuration files keep working. The big problem is hook
> support. Tarmac, like bzr it is based on, implements a particular hook
> mechanism where the hook is a python routine which has internal access
> to all the APIs of both launchpadlib and bzr. This is naturally
> unportable to python3 and git for obvious reasons.
>
> Given that I have no other data I will risk making statement that
> nobody uses those hooks as they are fairly complex and in some ways
> equate to having a local fork of tarmac itself as they have all the
> access to the core (trivia: did you know bzr has identical hooks? did
> you ever use bzr hooks?).
>
> Still, for the time being, I plan to work on incorporating any changes
> needed to support git in the current upstream tarmac codebase. I don't
> have a solid plan _yet_. I plan on having a look at the code to see
> what is possible. I may need to make some drastic changes, to
> de-couple it from bzrlib and python 2, and allow it to run without bzr
> installed. Next week I should have more details.
>
> If you are interested in the transition to git and are currently using
> something to merge your bzr branches please have a look at the
> prototype code linked below.
>
> Thanks
> ZK
>
> [1] https://git.launchpad.net/~zyga/+git/pmr/tree/process-merge-requests
>
> --
> Checkbox-devel mailing list
> Checkbox-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/checkbox-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/checkbox-devel/attachments/20150605/8aed5770/attachment.html>


More information about the Checkbox-devel mailing list