[Kolab-devel] Bugzilla (Re: Native Packaging, Issue Tracking & Restructuring the SCM)

Christoph Wickert wickert at kolabsys.com
Wed Sep 15 23:26:25 CEST 2010

On Wednesday 15 September 2010 18:19:51 Bernhard Reiter wrote:
> Am Mittwoch, 15. September 2010 17:41:02 schrieb Jeroen van Meeuwen (Kolab
> Systems):
> > 
> > In the OP I described that, amongst other things, it would be beneficial
> > to; enable separate components their have their own roadmap, milestones,
> > versioning,
> Saw that, the relation to the tracker was weak.

As the server release coordinator, I disagree:
- I want to have milestones in the tracker. I want to be able to assign a bug 
to a particular milestone. This is a transparent process, the submitter then 
know when a fix is expected to happen.
- I want to have tracker bugs so I can see the outstanding blockers and 
targets on a single glance.
- I'm tired of "oh, this bug should have made it into the 2.2.4 release, but 
obviously it hasn't". We have a couple of them in the 2.2.4 release.

> I have seen many of those trackers as well, currently we are also using
> Jira (I was forced to) and bugs.kde.org. And I have done thousands of
> transactions on issues.kolab.org.

But what about the people who have never worked with roundup? How should they 
know they are supposed to set keywords if they are not mandatory?

> Given my experience and the current workflow of ongoing client development
> I believe roundup is a better choice. 

Maybe it is, but you still did not name a single argument against bugzilla or 
pro roundup.

> I have not found bugzilla a good
> choice in most environments I have evaluated or used it.

A lot of client related work happens at bugs.kde.org, which happens to run 
bugzilla. So it cannot be that bad. Automatically checking for duplicates for 
example is a feature that is a great delight to the developers. I don't know 
any other bugtracker that offers this functionality.

> Workflow for development for us should be slightly modified of how it is
> working today. I believe it is better to improve a system evolutionary,
> especially when it is not broken.

I don't know the situation for the client, but for the server I consider it 
not to be functional (I don't dare to call it broken, but I'm sure others 


Christoph Wickert
Senior Engineer

Kolab Systems AG
Zürich, Switzerland

e: wickert at kolabsys.com
t: +49 251 871 369 77
w: http://kolabsys.com

pgp: 85DACC63 Christoph Wickert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20100915/f201d3e9/attachment.sig>

More information about the devel mailing list