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

[Jeroen van Meeuwen (Kolab Systems)]

Bernhard Reiter wrote:
> Am Mittwoch, 15. September 2010 17:41:02 schrieb Jeroen van Meeuwen (Kolab
> 
> Systems):
> > > can you give the rationale for changing the issue tracking system?
> > > I haven't seen it so far.
> > 
> > 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.
> 

Naturally, there's only so much one can say in a single email pitching one or 
more ideas.

I'm opening up discussion, or trying to, about what is to be to our mutual 
benefit. This doesn't set anything in stone even if someone chooses to 
illustrate the case in point by establishing a playground.

I think that, since most of (pragmatic) source code management, issue 
tracking, individual developer's processes as well as the overall project 
development processes, release engineering and management, support and mapping 
work on to a timeline (a.k.a. "the roadmap", possibly/optionally including 
funded development work for customers/partners if you choose to) are 
interleaved, and given that this one sentence spans 7 lines already... sure, I 
did not clarify everything that's going on in my mind in that email.

> > A list of requirements for an issue tracker are listed in the Summary
> > section of the aforementioned wiki page[1], which I can only hope you'll
> > find of useful assistance when determining whether Roundup or any other
> > issue tracker may be the most efficient and sustainable path forward from
> > where we are today.
> 
> Okay, I need to check it out then. You did not announce that the
> workflow of bugzilla would have the requirement analysis of the tracker.
> 
> > While possibly not mutually exclusive with the use of Roundup, since I am
> > very familiar with Mantis, RT, Bugzilla, Trac, OTRS and some of the
> > lesser systems for issue tracking, I choose what is, IMHO, the best
> > issue tracker to sustain the requirements for the Kolab community, out
> > of those I'm very familiar with, to illustrate what I have started in
> > OP.
> 
> 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.
> 

And so what is your opinion on the *illustration* of the case in point, which 
I started discussing in OP? Most prominently, this implementation offers a 
playground for how things like the following could work;

- products (currently grouped by client/server products),
- components,
- versions,
- milestones,
- resolved & closed statuses,
- established work-flow,
- review queues,
- notifications to people involved/interested,
- Quality Assurance contacts

Given that *that* is in fact the original case in point here, not the amount 
of experience the both of us may or may not have with any given issue tracker 
in existence, I'm looking forward to your general impression of what is in OP 
-besides the show-case implementation I did one Thursday-night in my own 
personal time, and besides whether I am personally capable or savvy enough of 
showing it through a Bugzilla instance somewhere or not.

If you think there's a reasonable path from where we are today, towards where 
we can all agree on, we need to be tomorrow/next week/next month/in a year, I 
am open to your suggestions.

> > > I have a strong preference against bugzilla.
> > 
> > Would you mind explaining that statement? I understand it to mean you're
> > fanatically against Bugzilla, but I'm not sure what the rationale behind
> > such a strong statement could be; I haven't seen it so far.
> 
> If you understood my statement of being "fanatically against bugzilla"
> without understanding that there could be possible reasons,
> you must have meant your statement as being fanatically for bugzilla
> as you also did not give your reasons either.
> 

I'm sorry should you have misunderstood me; I meant to argue that I am in 
favor, strong favor admittedly, of implementing the features I think are 
required to establish proper work-flows, policies and guidelines to further 
grow the community, to facilitate an increase of it's level of participation, 
to increase the Kolab community's participation with upstream parties, and to 
thus further the Kolab product -for fun and profit.

Looking forward to your feedback,

Kind regards,

-- 
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08