Hi Lenz, Lenz Grimmer wrote:
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.
Well it was first discussed when we were discussing my employment and secondly on a company conference call. There was no big email discussion before my email to the list.
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!
This is what I thought when I saw the news, it is something I certainly consider an option but I am not the user of the system.
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
If you have ever looked at the bugs.mysql.com code you will know why no one with any bit of sanity would run it.
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...
At the initial time of discussion there was no possible way to customize bugs on launchpad so using a 3rd party system was the only way to get some functionality we wanted. Eventum was chosen because I am familiar with it and can easily shape it to fit our needs. However since LP is now open source improving it is an option that we should explore.
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.
I haven't looked at the code nor do I use worklog on a daily basis so I am not going to comment on this portion. Best Regards, -- Bryan Alsdorf, Lead Web Developer Monty Program, AB. http://askmonty.org