[Maria-developers] Bug tracker for MariaDB
Hi, I am in the process of setting up Eventum as the bug tracker at Monty Program AB to track bugs in MariaDB. I would like input on the values we need for the following fields: * Status * Category * Operating Systems Also please suggest any additional fields you think should be in this system. The current fields I have are: * Summary * Severity * Category * Status * Operating System * Description * How to Repeat * Suggested Fix * Product * Product Version * BZR Tree (URL to relevant tree with bug fix or that illustrates the problem) Some of these fields (and my current values for them) are inspired by bugs.mysql.com. However, since we are setting up a brand new system we should try make it fit our needs instead of doing what others are doing. Any suggestions or comments are appreciated, once I finish the initial setup I will get a test site up for everyone to look over. Best Regards, -- Bryan Alsdorf, Lead Web Developer Monty Program, AB. http://askmonty.org
Hi Bryan, On 19/06/2009, at 8:01 AM, Bryan Alsdorf wrote:
I am in the process of setting up Eventum as the bug tracker at Monty Program AB to track bugs in MariaDB. [...] Any suggestions or comments are appreciated, once I finish the initial setup I will get a test site up for everyone to look over.
I would very very strongly suggest to use the bug tracking facilities at Launchpad. They're neatly linked to branches, allow people to follow, do linking to upstream bugtrackers, etc. OurDelta and Percona also use it, which again provides neat integration. Cheers, Arjen. -- Arjen Lentz, Director @ Open Query (http://openquery.com) Affordable Training and ProActive Support for MySQL & related technologies Follow our blog at http://openquery.com/blog/ OurDelta: free enhanced builds for MySQL @ http://ourdelta.org
Arjen, Arjen Lentz wrote:
Hi Bryan,
On 19/06/2009, at 8:01 AM, Bryan Alsdorf wrote:
I am in the process of setting up Eventum as the bug tracker at Monty Program AB to track bugs in MariaDB. [...] Any suggestions or comments are appreciated, once I finish the initial setup I will get a test site up for everyone to look over.
I would very very strongly suggest to use the bug tracking facilities at Launchpad. They're neatly linked to branches, allow people to follow, do linking to upstream bugtrackers, etc. OurDelta and Percona also use it, which again provides neat integration.
I am neutral on which solution to use. Some people have expressed the opinion that the bugtracking on Launchpad is rather limited so I was asked to set Eventum up. If Monty decides that Launchpad is sufficient for bugtracking I am happy to use it. Best Regards, /bryan
Hi Bryan, Monty On 19/06/2009, at 11:22 AM, Bryan Alsdorf wrote:
Arjen Lentz wrote:
I am in the process of setting up Eventum as the bug tracker at Monty Program AB to track bugs in MariaDB. [...] Any suggestions or comments are appreciated, once I finish the initial setup I will get a test site up for everyone to look over. I would very very strongly suggest to use the bug tracking facilities at Launchpad. They're neatly linked to branches, allow people to follow, do
Hi Bryan, On 19/06/2009, at 8:01 AM, Bryan Alsdorf wrote: linking to upstream bugtrackers, etc. OurDelta and Percona also use it, which again provides neat integration.
I am neutral on which solution to use. Some people have expressed the opinion that the bugtracking on Launchpad is rather limited so I was asked to set Eventum up. If Monty decides that Launchpad is sufficient for bugtracking I am happy to use it.
Launchpad is not perfect, but it does pretty well. Eventum for bugtracking wouldn't be ideal either, unless significant development work was done on it - and you don't have the time for that. Of the two non-ideals, I prefer launchpad, for all the above reasons. You know we can even mark a bug as relevant for more than one project, like MariaDB and OurDelta, or XtraDB and MariaDB, etc. I can cope with the less-than-perfect user-interface. These inter- project intergration things are now very important things to consider. Cheers, Arjen. -- Arjen Lentz, Director @ Open Query (http://openquery.com) Affordable Training and ProActive Support for MySQL & related technologies Follow our blog at http://openquery.com/blog/ OurDelta: free enhanced builds for MySQL @ http://ourdelta.org
Hi!
"Arjen" == Arjen Lentz <arjen@openquery.com> writes:
Arjen> Hi Bryan, Monty Arjen> On 19/06/2009, at 11:22 AM, Bryan Alsdorf wrote:
Arjen Lentz wrote:
I am in the process of setting up Eventum as the bug tracker at Monty Program AB to track bugs in MariaDB. [...] Any suggestions or comments are appreciated, once I finish the initial setup I will get a test site up for everyone to look over. I would very very strongly suggest to use the bug tracking facilities at Launchpad. They're neatly linked to branches, allow people to follow, do
Hi Bryan, On 19/06/2009, at 8:01 AM, Bryan Alsdorf wrote: linking to upstream bugtrackers, etc. OurDelta and Percona also use it, which again provides neat integration.
I am neutral on which solution to use. Some people have expressed the opinion that the bugtracking on Launchpad is rather limited so I was asked to set Eventum up. If Monty decides that Launchpad is sufficient for bugtracking I am happy to use it.
Arjen> Launchpad is not perfect, but it does pretty well. Arjen> Eventum for bugtracking wouldn't be ideal either, unless significant Arjen> development work was done on it - and you don't have the time for that. Actually, Bryan should have time for that; As far as I know he will spend the 20 % of his "free time" to work on Eventum and there are also others that would like to have Eventum as a bug tracker. Regards, Monty
Hi Monty On 24/06/2009, at 12:01 AM, Michael Widenius wrote:
"Arjen" == Arjen Lentz <arjen@openquery.com> writes: Arjen> On 19/06/2009, at 11:22 AM, Bryan Alsdorf wrote: Arjen Lentz wrote: Hi Bryan, On 19/06/2009, at 8:01 AM, Bryan Alsdorf wrote: I am in the process of setting up Eventum as the bug tracker at Monty Program AB to track bugs in MariaDB. [...] Any suggestions or comments are appreciated, once I finish the initial setup I will get a test site up for everyone to look over. I would very very strongly suggest to use the bug tracking facilities at Launchpad. They're neatly linked to branches, allow people to follow, do linking to upstream bugtrackers, etc. OurDelta and Percona also use it, which again provides neat integration.
I am neutral on which solution to use. Some people have expressed the opinion that the bugtracking on Launchpad is rather limited so I was asked to set Eventum up. If Monty decides that Launchpad is sufficient for bugtracking I am happy to use it.
Arjen> Launchpad is not perfect, but it does pretty well.
Arjen> Eventum for bugtracking wouldn't be ideal either, unless significant Arjen> development work was done on it - and you don't have the time for that.
Actually, Bryan should have time for that; As far as I know he will spend the 20 % of his "free time" to work on Eventum and there are also others that would like to have Eventum as a bug tracker.
Ok, but I don't regard those two arguments (Bryan has time for it and others are asking for it) as a convincing argument for having MariaDB use this as a bugtracker. As I mentioned above, the bugtracking system at Launchpad works pretty well, integrated very well with the bzr branches, and so on. Considering MariaDB does interact with other projects for part of its codebase and other purposes, why not use something that already works rather than putting in extra? Look Monty, I like Eventum, Open Query uses it for some things also, but that's really not the issue here. If Launchpad bug tracking has some issues, we can identify them, report them, and see if they can be addressed. We know the people who build it and we know they're active and open to suggestions. Just seems like a better way to use time and other resources, with a more satisfactory result for not just MariaDB but also others. Wheel-reinventing is terribly distracting and wasteful. Cheers, Arjen. -- Arjen Lentz, Director @ Open Query (http://openquery.com) Affordable Training and ProActive Support for MySQL & related technologies Follow our blog at http://openquery.com/blog/ OurDelta: free enhanced builds for MySQL @ http://ourdelta.org
Hi, I hope I'm not beating on a dead horse here, I just stumbled over this thread and wanted to drop my 2 Cents into the hat :) On 06/24/2009 12:33 AM, Arjen Lentz wrote:
Ok, but I don't regard those two arguments (Bryan has time for it and others are asking for it) as a convincing argument for having MariaDB use this as a bugtracker. As I mentioned above, the bugtracking system at Launchpad works pretty well, integrated very well with the bzr branches, and so on. Considering MariaDB does interact with other projects for part of its codebase and other purposes, why not use something that already works rather than putting in extra?
Look Monty, I like Eventum, Open Query uses it for some things also, but that's really not the issue here.
If Launchpad bug tracking has some issues, we can identify them, report them, and see if they can be addressed. We know the people who build it and we know they're active and open to suggestions. Just seems like a better way to use time and other resources, with a more satisfactory result for not just MariaDB but also others. Wheel-reinventing is terribly distracting and wasteful.
I concur with Arjen here. The integration of the Launchpad Bug tracker with Bazaar trees and other Launchpad features like the cross-referencing between other external bug trackers are very compelling. I've been using the Launchpad bug tracker for keeping a tab on the mylvmbackup bugs and I really like its functionality. One nice feature for example is the way in which it searches the database for existing reports when you start with your own bug report. Also consider the user experience: they would have to learn yet another bug reporting interface. Keep it simple and don't reinvent the wheel, just because you can. I was horrified when I learned that you have chosen to use the ugly and collaboration-unfriendly WorkLog system again, instead of just utilizing Lauchpad Blueprints... Bye, LenZ -- Lenz Grimmer <lenz@grimmer.com> - http://www.lenzg.net/
Guys, Let me say my vote here. I think it is critically important to have bugtracker that can be intergrade with third-part projects (patches, PBXT, XtraDB). I am asking to seriously reconsider and use Launchpad project. it may be not convenient in some ways, but it works. On Tue, Jul 7, 2009 at 4:53 AM, Lenz Grimmer <lenz@grimmer.com> wrote:
Hi,
I hope I'm not beating on a dead horse here, I just stumbled over this thread and wanted to drop my 2 Cents into the hat :)
On 06/24/2009 12:33 AM, Arjen Lentz wrote:
Ok, but I don't regard those two arguments (Bryan has time for it and others are asking for it) as a convincing argument for having MariaDB use this as a bugtracker. As I mentioned above, the bugtracking system at Launchpad works pretty well, integrated very well with the bzr branches, and so on. Considering MariaDB does interact with other projects for part of its codebase and other purposes, why not use something that already works rather than putting in extra?
Look Monty, I like Eventum, Open Query uses it for some things also, but that's really not the issue here.
If Launchpad bug tracking has some issues, we can identify them, report them, and see if they can be addressed. We know the people who build it and we know they're active and open to suggestions. Just seems like a better way to use time and other resources, with a more satisfactory result for not just MariaDB but also others. Wheel-reinventing is terribly distracting and wasteful.
I concur with Arjen here. The integration of the Launchpad Bug tracker with Bazaar trees and other Launchpad features like the cross-referencing between other external bug trackers are very compelling. I've been using the Launchpad bug tracker for keeping a tab on the mylvmbackup bugs and I really like its functionality. One nice feature for example is the way in which it searches the database for existing reports when you start with your own bug report.
Also consider the user experience: they would have to learn yet another bug reporting interface.
Keep it simple and don't reinvent the wheel, just because you can.
I was horrified when I learned that you have chosen to use the ugly and collaboration-unfriendly WorkLog system again, instead of just utilizing Lauchpad Blueprints...
Bye, LenZ -- Lenz Grimmer <lenz@grimmer.com> - http://www.lenzg.net/
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers<https://launchpad.net/%7Emaria-developers> Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers<https://launchpad.net/%7Emaria-developers> More help : https://help.launchpad.net/ListHelp
I agree with Lenz and Vadim on this one. The Launchpad bug tracker is not perfect but I find it quite sufficient. The user interface is easy to use which is important. But, the greatest advantage is the close integration with the rest of Launchpad. On Jul 7, 2009, at 7:31 PM, Vadim Tkachenko wrote:
Guys,
Let me say my vote here.
I think it is critically important to have bugtracker that can be intergrade with third-part projects (patches, PBXT, XtraDB). I am asking to seriously reconsider and use Launchpad project. it may be not convenient in some ways, but it works.
On Tue, Jul 7, 2009 at 4:53 AM, Lenz Grimmer <lenz@grimmer.com> wrote: Hi,
I hope I'm not beating on a dead horse here, I just stumbled over this thread and wanted to drop my 2 Cents into the hat :)
On 06/24/2009 12:33 AM, Arjen Lentz wrote:
Ok, but I don't regard those two arguments (Bryan has time for it and others are asking for it) as a convincing argument for having MariaDB use this as a bugtracker. As I mentioned above, the bugtracking system at Launchpad works pretty well, integrated very well with the bzr branches, and so on. Considering MariaDB does interact with other projects for part of its codebase and other purposes, why not use something that already works rather than putting in extra?
Look Monty, I like Eventum, Open Query uses it for some things also, but that's really not the issue here.
If Launchpad bug tracking has some issues, we can identify them, report them, and see if they can be addressed. We know the people who build it and we know they're active and open to suggestions. Just seems like a better way to use time and other resources, with a more satisfactory result for not just MariaDB but also others. Wheel-reinventing is terribly distracting and wasteful.
I concur with Arjen here. The integration of the Launchpad Bug tracker with Bazaar trees and other Launchpad features like the cross-referencing between other external bug trackers are very compelling. I've been using the Launchpad bug tracker for keeping a tab on the mylvmbackup bugs and I really like its functionality. One nice feature for example is the way in which it searches the database for existing reports when you start with your own bug report.
Also consider the user experience: they would have to learn yet another bug reporting interface.
Keep it simple and don't reinvent the wheel, just because you can.
I was horrified when I learned that you have chosen to use the ugly and collaboration-unfriendly WorkLog system again, instead of just utilizing Lauchpad Blueprints...
Bye, LenZ -- Lenz Grimmer <lenz@grimmer.com> - http://www.lenzg.net/
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
-- Paul McCullagh PrimeBase Technologies www.primebase.org www.blobstreaming.org pbxt.blogspot.com
Hi!
"Vadim" == Vadim Tkachenko <vadim@percona.com> writes:
Vadim> Guys, Vadim> Let me say my vote here. Vadim> I think it is critically important to have bugtracker that can be intergrade Vadim> with third-part projects (patches, PBXT, XtraDB). Vadim> I am asking to seriously reconsider and use Launchpad project. it may be not Vadim> convenient in some ways, but it works. 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. 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. <cut>
Ok, but I don't regard those two arguments (Bryan has time for it and others are asking for it) as a convincing argument for having MariaDB use this as a bugtracker. As I mentioned above, the bugtracking system at Launchpad works pretty well, integrated very well with the bzr branches, and so on. Considering MariaDB does interact with other projects for part of its codebase and other purposes, why not use something that already works rather than putting in extra?
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.
Look Monty, I like Eventum, Open Query uses it for some things also, but that's really not the issue here.
If Launchpad bug tracking has some issues, we can identify them, report them, and see if they can be addressed. We know the people who build it and we know they're active and open to suggestions.
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.
Just seems like a better way to use time and other resources, with a more satisfactory result for not just MariaDB but also others. Wheel-reinventing is terribly distracting and wasteful.
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 concur with Arjen here. The integration of the Launchpad Bug tracker with Bazaar trees and other Launchpad features like the cross-referencing between other external bug trackers are very compelling. I've been using the Launchpad bug tracker for keeping a tab on the mylvmbackup bugs and I really like its functionality. One nice feature for example is the way in which it searches the database for existing reports when you start with your own bug report.
Also consider the user experience: they would have to learn yet another bug reporting interface.
Keep it simple and don't reinvent the wheel, just because you can.
I was horrified when I learned that you have chosen to use the ugly and collaboration-unfriendly WorkLog system again, instead of just utilizing Lauchpad Blueprints...
Launchpad Blueprints can't be used as it lacks many of the features we are using in worklog. 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. Regards, Monty
Just to ask a stupid question first: It seems to me at the moment we *are* using bugs.launchpad.net/maria as the only bugtracker, aren't we?
"Vadim" == Vadim Tkachenko <vadim@percona.com> writes: Vadim> I think it is critically important to have bugtracker that can be intergrade Vadim> with third-part projects (patches, PBXT, XtraDB). Vadim> I am asking to seriously reconsider and use Launchpad project. it may be not Vadim> convenient in some ways, but it works.
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.
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.
I kind of agree with Monty. I hadn't looked at the launchpad system this closely before, but it kind of looks like an Apple/Gnome app. Nice graphics, but minimalistic in functionality :-) It is good if a tool enforces procedure, which actually the MySQL bug system was good at: The bug is not just "assigned" to someone, but there is a reviewer, test lead, documenting, etc... *and* the person actually fixing the bug. Same for the Status messages That being said, we should always strive to - not reinvent wheel, including not host things ourselves if we don't have to. - use popular tools rather than less well known or home-made (Eventum is used for MySQL, but Bugzilla, Trac etc are generally more popular so if we enhance them, there is a larger community that benefits.) - listen to community input, which seems quite unanimous in this thread Imho this is a perfect opportunity to engage in some deeper dialogue here before committing to a non-launchpad solution: Bryan: You are actually working on this, right? Could you spend 15-30 minutes on a rough requirements list - for *any* bug tracker, starting from what Monty mentioned: - categories needed (we probably don't need a set of categories, but the ability to define our own, right?) - status categories needed - fields needed, including "roles" more then "Assigned to" - general workflow that must be supported and possibly *enforced* by the tool - pingback to bugs.mysql.com (which launchpad *does* have!) We (bryan, kurt) should then at least ask Canonical for a comment on our feedback before giving up on them. Finally, if a non-launchpad solution is needed, we should very briefly evaluate and explain (to me) the feasibility of Bugzilla and Trac. As for Trac I have friends in Spain and they use it not only as bug tracker, but also project management including planning, tracking and reporting of hours on customer and government funded projects. I personally wouldn't mind if we ended up using Trac. Bryan, could you please reply to me if you have time to handle this? If you were already doing something else, please update me. henrik -- email: henrik.ingo@avoinelama.fi tel: +358-40-5697354 www: www.avoinelama.fi/~hingo book: www.openlife.cc
Hi Henrik, Henrik Ingo wrote:
Just to ask a stupid question first: It seems to me at the moment we *are* using bugs.launchpad.net/maria as the only bugtracker, aren't we?
Yes, at the moment we are only using launchpad, however we only have 7 bugs there total. <snip>
I kind of agree with Monty. I hadn't looked at the launchpad system this closely before, but it kind of looks like an Apple/Gnome app. Nice graphics, but minimalistic in functionality :-) It is good if a tool enforces procedure, which actually the MySQL bug system was good at: The bug is not just "assigned" to someone, but there is a reviewer, test lead, documenting, etc... *and* the person actually fixing the bug. Same for the Status messages
That being said, we should always strive to - not reinvent wheel, including not host things ourselves if we don't have to. - use popular tools rather than less well known or home-made (Eventum is used for MySQL, but Bugzilla, Trac etc are generally more popular so if we enhance them, there is a larger community that benefits.) - listen to community input, which seems quite unanimous in this thread
Eventum isn't as widely used as Bugzilla or Trac but it does have many users. It also is quite popular in the MySQL community (Percona and OpenQuery use it for support).
Imho this is a perfect opportunity to engage in some deeper dialogue here before committing to a non-launchpad solution:
Bryan: You are actually working on this, right? Could you spend 15-30 minutes on a rough requirements list - for *any* bug tracker, starting from what Monty mentioned:
- categories needed (we probably don't need a set of categories, but the ability to define our own, right?) - status categories needed - fields needed, including "roles" more then "Assigned to" - general workflow that must be supported and possibly *enforced* by the tool - pingback to bugs.mysql.com (which launchpad *does* have!)
I am happy to come up with a list except I really don't have a grasp on what we need, I was trying to get this data from maria-developers@ which is what prompted this thread. The developers need to let me know what is important to them and I can compile the requirements.
We (bryan, kurt) should then at least ask Canonical for a comment on our feedback before giving up on them.
Finally, if a non-launchpad solution is needed, we should very briefly evaluate and explain (to me) the feasibility of Bugzilla and Trac. As for Trac I have friends in Spain and they use it not only as bug tracker, but also project management including planning, tracking and reporting of hours on customer and government funded projects. I personally wouldn't mind if we ended up using Trac.
I do agree that we should evaluate multiple options but if we go with a non-launchpad solution I lean heavily towards Eventum simple because we can shape it any way we want. Best Regards, -- Bryan Alsdorf, Lead Web Developer Monty Program, AB. http://askmonty.org
On Fri, Jul 17, 2009 at 9:17 AM, Bryan Alsdorf<bryan@askmonty.org> wrote:
Eventum isn't as widely used as Bugzilla or Trac but it does have many users. It also is quite popular in the MySQL community (Percona and OpenQuery use it for support).
This is a good point. You could argue it is popular/widely used in it's local context, even if not globally. henrik -- email: henrik.ingo@avoinelama.fi tel: +358-40-5697354 www: www.avoinelama.fi/~hingo book: www.openlife.cc
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@grimmer.com> - http://www.lenzg.net/
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
On Thu, Jun 18, 2009 at 05:01:56PM -0500, Bryan Alsdorf wrote:
I am in the process of setting up Eventum as the bug tracker at Monty Program AB to track bugs in MariaDB. I would like input on the values we need for the following fields: * Status * Category * Operating Systems
Also please suggest any additional fields you think should be in this system. The current fields I have are: * Summary * Severity * Category * Status * Operating System * Description * How to Repeat * Suggested Fix * Product * Product Version * BZR Tree (URL to relevant tree with bug fix or that illustrates the
historically have found it really hard in the mysql bug tracker to do reasonable searches on OS. Especially if something is Linux 2.4 specific or Linux 2.6 specific. So there could be a difference between "observed on" and "affects". e.g. bug could be found on Linux 2.4.18 but affects all of 2.4 series and none of 2.6 (think O_DIRECT :) problem) launchpad can have several branches linked to the one bug - a useful feature sometimees. it also lets you link to other bug trackers. could be useful here too - linking back to MySQL bug tracker or Drizzle bug tracker (launchpad). -- Stewart Smith
participants (8)
-
Arjen Lentz -
Bryan Alsdorf -
Henrik Ingo -
Lenz Grimmer -
Michael Widenius -
Paul McCullagh -
Stewart Smith -
Vadim Tkachenko