maria-developers team mailing list archive

[Lenz Grimmer <lenz@xxxxxxxxxxx>]

Hi,

given the recent news about Launchpad, I'd like to contribute another comment,
bearing the risk of beating a dead horse...

On 07/15/2009 05:11 PM, Michael Widenius wrote:

> We have internally just been discussing the possibility to use Eventum
          ^^^^^^^^^^
> for a bug tracker as we probably want to use Eventum for other things
> internally in Monty Program Ab anyway.

Any reason why this discussion was not done in public? I thought that having
an open public dialog with the community is one of the key aspects of your
company? Just wondering.

And note that we're not arguing against using Eventum where it fits the
purpose! We're merely questioning its suitability as a bug tracking tool and
the need for modifying it to become one.

> The problem with the Launchpad bug system is that it's inferior in
> many aspect to what for example MySQL's bug tracking systems is.
> It's so much extra work that needs to be done to get to this level
> that I don't think that the Launchpad developers will ever do it.

Well, now that the Launchpad code base has been released as Open Source, you
can actually do it yourself and contribute your improvements back!

  https://dev.launchpad.net/

> Because the Launchpad system doesn't look like it will work when we
> get lots of bug reports in different areas.  It's also very limited
> in the number of fields, categories, bug solving steps etc.

Have you looked at how the Ubuntu project uses the Launchpad bug tracker? Or
Drizzle? If they are able to work with it, why shouldn't you?

I've worked with a number of bug tracking systems in my career (primarily
Bugzilla, the MySQL bug tracker and now Launchpad bugs). From all of these,
the Launchpad bug tracker was the most convenient one to use and provided just
enough functionality without becoming overwhelmingly complex or cumbersome to
use. Plus it beats all other systems when it comes to integration with the
source code management system.

> Don't think that will work.  For example, one could point to the MySQL
> bug system and say that we would like to have all categories and all
> fields that exists in the MySQL bug system. When this is done, then we
> can start talking about the other features that doesn't exists.

The question remains if all these fields are really necessary. The MySQL bug
tracker has become quite convoluted with fields. Or are you just trying to
continue using a similar system because you are used to it? In that case you
could just branch off the source of bugs.mysql.com:

 bzr branch http://bugs.mysql.com/bzr/ bugs.mysql.com

> Agree that reinventing a wheel is a distraction. But so is trying to
> use a square wheel and claim that 'it works for me so it should work
> for you'.

I am not convinced, but in the end it's your decision, time and money...

> Launchpad Blueprints can't be used as it lacks many of the features we
> are using in worklog.

Again, now is your chance to fix and improve them :)

> Actually, we are extending worklog to make it collaboration friendly
> and it as far as I can see, it will be more collaboration friendly
> that we could ever do with Launchpad.

I believe it when I see it - the WorkLog code base is quite a convoluted mess
and anyone having to hack on this has my sympathies.

Bye,
	LenZ
-- 
  Lenz Grimmer <lenz@xxxxxxxxxxx> - http://www.lenzg.net/

Attachment: signature.asc
Description: OpenPGP digital signature