最近，完成了对Bugzilla插件的重写，重新实现为GTG的同步服务（Synchronization Service）。不得而知是何原因需要做这个转换。 您可以从 Bug 494967 略之一二。
原始的插件实现提供了基本的Bug信息同步功能。在用户输入一个Bug链接后，Bugzilla插件会得到GTG的通知，根据URL中提供的远程Bugzilla服务的信息， 与之通信读取Bug信息并替换任务的主题和内容。同时，会把Bug的Component作为任务的标签。除了这些基本功能外，在我看来，有一点不足非常明显，即可配置程度不高。它体现在几个方面。
一是，所支持的Bugzilla服务是不可配置的。这些服务是写死在代码里的，导致用户无法添加一个GTG尚未知晓的Bugzilla服务。
二是，标签同步的来源是不可配置的。标签的来源也是在代码里写死。用户没有任何选择的权力。Priority、Severity等Bug属性都是可以用作标签的很好的选择。 如果有用户需要使用它们作为标签，则必须身体力行地亲自修改代码才行。另外，如果用户想指定额外的名称作为标签，要么同样亲力亲为，要么就只能指望GTG的开发者实现了。 显然这不够理想。
在开始重新实现为同步服务之前，我希望尽可能地不对原始的同步行为和结果做任何改动，以便保持用户原有的用户体验。此外，既然是重新实现， 也正好是重新思考如何实现一个更好的同步功能的好机会，借机改进Bugzilla同步服务，修改掉一些已知的问题。下面几点是重写过程中所保持的和做出的改进。
一、保持Bug同步的原始行为不变。不改变已有的用户体验。
二、标签同步的来源可配置。可指定哪些Bug属性可作为标签，以及可以输入自定义的标签名称。目前还不允许用户将任意的Bug属性指定为标签。 尽管各个Bugzilla服务都是基于相同 Bugzilla 项目，但不同的开源项目有其各自独特的管理需求，使得Bug属性也不尽相同。 即便如此，它们也是有相同的部分，例如Priority、Severity、Component和Status等。这些属性对于开发者来说，都是有意义的。我决定在目前的版本中， 首先支持这些共有的且极具实际用途的Bug属性。这样也能够降低在Bugzilla服务之间处理不同的Bug属性差异所带来的复杂度。
三、提供默认支持的Bugzilla服务列表，也允许用户增、删、改。在使用中，删除和编辑的可能性是不大的。没有哪个项目会经常变动自己Bugzilla服务的域名。 但也显然的是，默认的列表不能穷举所有已经存在的Bugzilla服务。增的操作对于某些用户来说就显得很有必要。
四、允许将Bug的第一个Comment的内容作为任务的内容添加到任务中。这是一个很有用的选项。从我个人的角度来看，这个功能非常的有价值， 应该作为同步的一个步骤默认地提供给用户而不是作为选项。然而，为了保持原有的插件的同步行为不变，只能将此作为选项提供，且默认不勾选。
五、更友好的信息提示机制。在同步Bug信息的过程中，可能会遇到各种各样的意外情况。其中有一部分是应该让用户知道的。比如，用户没有权限读取某个Bug， 或者由于网络原因暂时不能同步Bug信息等。在原始的插件实现中，以及最初的同步服务实现中，我采取操作系统的通知机制（通过pynotify提供）向用户发送各种信息。 实践证明，尽管这种方式解决了问题，在GNOME和KDE以及其他常见的桌面环境中能够以相对友好的方式显示提示消息，但似乎与GTG有些脱节。 GTG自己提供了内置的消息提示机制。集成的通知机制，交互方便，能够将用户的注意力集中于在GTG上发生的所有的操作上。这有助于提高用户的操作效率。 Bugzilla同步服务即使用了此机制向用户推送必要的消息。
目前，已经完成了第一个目标。同步功能能够正常工作。Bugzilla同步服务的配置对话框如下图1所示。
同步结果入下图2所示。
从上图中能看到，已经有两个两个任务获得了对应的Bug的信息。另外两个没有同步成功，其中一个原因被显示在了对话框中央的提示区域中。
您可以从这里获得代码尝鲜， https://github.com/getting-things-gnome/gtg/pull/55
Bugzilla同步服务的配置功能还没有完成。这是下一步要完成的工作。不得不提的是，同步服务的配置对话框限制了开发者向其添加自定义窗口部件的能力。 GTG采取了声明式的实现方式。它内置了有限的几种对应到不同类型的配置参数的窗口部件。配置区域是自动生成的。不爽的是，它没有暴露必要的接口以允许 开发者添加自定义的内容。历经近一段时间的摸索，没有得到任何答案。GTG的开发者邮件列表也没有反馈。所以，在上图1中，您没有看到默认提供的Bugzilla服务的列表。 接下来，这是首要解决的问题。
