Moving Bugzilla to git?

Mark Côté mcote at mozilla.com
Wed Oct 30 17:05:04 UTC 2013


I do not have the same understanding vis-à-vis bzr-git. I tried to use
the bzr-git extension, and it failed when I tried to pull in changes
from git. This was a git repo generated using a different tool,
admittedly (bzr fast-export | git fast-import), but I exchanged some
emails with bzr-git's author, Jelmer Vernooij, and he said that to keep
an existing bzr branch in sync with a newly formed git repo is
impossible at the moment: "This is essentially the 'roundtripping'
support that we've been trying to achieve with bzr-git for a while. It's
a nontrivial problem (since it requires all semantics from bzr to be
preserved when pushing to git)."

That said, as I mentioned before, it should be possible to create a
script to apply diffs from git to bzr in a similar way that we do
bzr-cvs mirroring right now. I have that script about half finished. So
there is no technical problem in doing one-way mirroring, as far as I
can tell.

So to sum up this thread, I don't hear any opposition to making git the
main VCS for Bugzilla and switching the existing Bazaar repo to
read-only. The only point of contention appears to be how long we keep
the Bazaar repos. This is partly a question for Mozilla's IT, since they
are looking to retire older systems to remove some maintenance load. I
don't think we need to solve it immediately, though. I will talk to the
IT department about their plans. Also I want to reiterate that we do
publish diffs with every release, so it's not like there is no way to
get a security fix even if bzr is shut down and installing git is
impossible, although pulling from bzr is of course more convenient.

As for git versus GitHub, the standard practice at Mozilla is to have
the primary repo exist on git.mozilla.org and create a one-way mirror to
GitHub. This makes sense to me, since we will have more control over the
repo. However, it also means that we wouldn't be able to merge pull
requests from the GitHub UI, but since we'd keep using Bugzilla and its
review tools, this doesn't really matter anyway. People can still fork
the code and easily generate diffs for review.

I will continue my work on the script and documentation. I've also
started a wiki page
(https://wiki.mozilla.org/Bugzilla:Migrating_to_git); I'll start filling
it in with the results of this discussion and sketch out a plan.

In the mean time, if you want to see the results of a migration, I just
pushed a snapshot of Bugzilla trunk to my GitHub account:
https://github.com/markrcote/bugzilla. I modified an existing
translation script to paste the contents of the "bugs" commit property
from Bazaar into the commit message, since git does not have commit
properties.

Mark


On 10/30/2013, 10:35 AM, Stephanie Daugherty wrote:
> The pain points of moving from cvs or svn to anything else largely don't
> exist for this conversion, because git, hg, and bzr are all at similar
> levels of functionality and interoperability to allow near
> interchangeability of tools, and common subsets of operations which can be
> performed across different repositories (push, pull, commit, merge, branch,
> tag, etc) using the cross-protocol support of each tool. (git can pretend a
> bzr repository is a git repository, bzr can pretent a git repository is a
> bzr repository, etc).
>
> My understanding is that the git-bzr integration is at a level sufficient
> to support a mirror suitable for nearly all upgrade/deployment scenarios,
> and the needs of many developers (history, tags and branches are 1:1 the
> same, submodules and certian metadata, like linkages to bug databases may
> not be). This support is also bidirectional, so it's technically possible
> to move in the other direction or even both directions at the same time,
> and to merge freely between the two systems, rather than being an all or
> nothing, one time conversion,
>
> This seems to be good enough that post-conversion, it would be possible to
> keep the bzr repositories up, while shifting development to git as of the
> time of transition, and continuing to mirror git to bzr without any
> technical limitations forcing an arbitrary cutoff point.
>
>
>
>
> On Wed, Oct 30, 2013 at 9:51 AM, Gervase Markham <gerv at mozilla.org> wrote:
>
>> On 29/10/13 18:58, Frédéric Buclin wrote:
>>> This clearly shows that you don't maintain any real Bugzilla
>>> installation.
>> Actually, I do.
>>
>>> "Install git, move from bzr to git, then upgrade your
>>> Bugzilla to get security fixes" is extra work which not all admins are
>>> ready to do.
>> It would be wise for admins to do the "Install git, move from bzr to
>> git" part before they needed to get a security fix...
>>
>>> This is maybe fine for developers, but certainly not for
>>> all admins. If you are happy with git, feel free to use it to maintain
>>> your Bugzilla installation, but this shouldn't affect installations
>>> already using bzr to get security fixes.
>> I guess this is one for justdave:
>>
>> "Is it reasonable to require Bugzilla administrators to switch SCM
>> system on an occasion other than a release upgrade?"
>>
>> If the answer is yes, we can shut down bzr fairly soon. If the answer is
>> no, we need to maintain it until all current branches are EOLed.
>>
>> Gerv
>> _______________________________________________
>> dev-apps-bugzilla mailing list
>> dev-apps-bugzilla at lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
>> -
>> To view or change your list settings, click here:
>> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>
>>
> _______________________________________________
> dev-apps-bugzilla mailing list
> dev-apps-bugzilla at lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>




More information about the developers mailing list