We've been wanting to switch from the extraordinarily painful SF bug tracker. Initially I thought we should host the service, but we don't have people with the expertise and time to do it, esp. given the DOS attack Inkscape suffered last week.
Ted, Kees, and I are investigating Launchpad, and think it will give all-around improvement with no regressions. Mental and ACSpike also thought Launchpad sounded like a good option. Bulia and other heavy bug tracker users - can you give a thumbs up that this would be worth trying?
Launchpad has the usual advanced bug tracking capabilities we've been badly missing, like proper bug duping, auto dupe detection, email interface, milestoning, tagging, SVN/CVS/etc.-integration, and so on. It also allows linking to upstream and downstream bug trackers, so we will be able to hook Inkscape bugs to corresponding Gtk, Cairo, etc. bugs (this is an extremely handy feature).
We're here local with the Launchpad engineers, so it would be a good opportunity for us to have them run their import scripts and set up a public demo site for us. They'll also provide the exported data files, in case we would choose to go with something different.
Bryce
On 2007-November-06 , at 07:21 , Bryce Harrington wrote:
We've been wanting to switch from the extraordinarily painful SF bug tracker. Initially I thought we should host the service, but we don't have people with the expertise and time to do it, esp. given the DOS attack Inkscape suffered last week.
Ted, Kees, and I are investigating Launchpad, and think it will give all-around improvement with no regressions. Mental and ACSpike also thought Launchpad sounded like a good option. Bulia and other heavy bug tracker users - can you give a thumbs up that this would be worth trying?
Even though I am not a "heavy bufg tracker user" I find SourceForge's system painful the few times I use it. The two things I would really like to see improved are: - speed: for me, SF system pain resides mostly in the fact that it is sloooow - less distinction between bugs, feature requests and patches and work with a single "ticket" system, a la Trac, in which tickets can be tagged, tracked and anything can be attached. The reason why I think the distinction is useless are: 1) most people (users) have a hard time distinguishing bugs and RFEs: an unexpected behavior can either be a bug in how a feature is coded or a design decision (or absence of decision) and the exected behavior should be requested. From a user point of view, there is often no way to distinguish those. 2) when patches are submitted, they either address a bug or provide new functionality, so theit logical place is inside a bug report or a feature request IMHO.
Launchpad has the usual advanced bug tracking capabilities we've been badly missing, like proper bug duping, auto dupe detection, email interface, milestoning, tagging, SVN/CVS/etc.-integration, and so on. It also allows linking to upstream and downstream bug trackers, so we will be able to hook Inkscape bugs to corresponding Gtk, Cairo, etc. bugs (this is an extremely handy feature).
Does this also means migrating the source code repository from SourceForge's SVN to Launchpad Bazaar?
We're here local with the Launchpad engineers, so it would be a good opportunity for us to have them run their import scripts and set up a public demo site for us. They'll also provide the exported data files, in case we would choose to go with something different.
JiHO --- http://jo.irisson.free.fr/
On Tue, Nov 06, 2007 at 10:34:49AM +0100, jiho wrote:
Even though I am not a "heavy bufg tracker user" I find SourceForge's system painful the few times I use it. The two things I would really like to see improved are:
- speed: for me, SF system pain resides mostly in the fact that it is
sloooow
Agreed. Exacerbating that is that you often have to do a series of clicks to do fairly simple things, which means if your network has any lag it makes everything more painful. I like Launchpad's design better in that most operations require only one page save/load, so you can get through a large volume of bugs reasonably swiftly, even if you're on a flaky hotel wireless network (a common use case for me these days).
- less distinction between bugs, feature requests and patches and
work with a single "ticket" system, a la Trac, in which tickets can be tagged, tracked and anything can be attached. The reason why I think the distinction is useless are: 1) most people (users) have a hard time distinguishing bugs and RFEs: an unexpected behavior can either be a bug in how a feature is coded or a design decision (or absence of decision) and the exected behavior should be requested. From a user point of view, there is often no way to distinguish those. 2) when patches are submitted, they either address a bug or provide new functionality, so theit logical place is inside a bug report or a feature request IMHO.
Right, so these are issues rather inherent in the design of the SF bug tracker, so just about any bug tracker change would address this.
In Launchpad there's a checkbox to check when uploading a file that is a patch. I think this is basically how most bug trackers do it. The search tools also allow constraining searches to bugs with patches attached, which seems to solve that aspect.
For RFE's, these are just marked as "Wishlist" priority in Launchpad. I think that's pretty standard too.
The Launchpad team will be importing all three classes for us, and they'll end up sorted into the appropriate categories.
SF's tracker also has a couple ways to sort bugs - by category (UI, renderer, text, etc.) and group (BSD, Linux, Windows...) Launchpad has a much more flexible tagging system, that allows giving a bug arbitrary numbers of tags, and enables users to define new tags.
Tagging can be done independently of the bug reporting and can be done by non-admins. There are also scripts that use the email interface to do bulk tagging operations, which can be handy when dealing with large quantities of bugs programmatically.
Launchpad has the usual advanced bug tracking capabilities we've been badly missing, like proper bug duping, auto dupe detection, email interface, milestoning, tagging, SVN/CVS/etc.-integration, and so on. It also allows linking to upstream and downstream bug trackers, so we will be able to hook Inkscape bugs to corresponding Gtk, Cairo, etc. bugs (this is an extremely handy feature).
Does this also means migrating the source code repository from SourceForge's SVN to Launchpad Bazaar?
No, although we did discuss changing VCS's last night (more focused on git than bzr), but it might be too disruptive to change it here going into a release.
Launchpad supports integration with a variety of different VCS systems including svn and bzr, and plans adding git and probably others. So I think if we decide to change VCS, that can be decided pretty much independently.
Bryce
On 11/6/07, Bryce Harrington <bryce@...961...> wrote:
We've been wanting to switch from the extraordinarily painful SF bug tracker. Initially I thought we should host the service, but we don't have people with the expertise and time to do it, esp. given the DOS attack Inkscape suffered last week.
Ted, Kees, and I are investigating Launchpad, and think it will give all-around improvement with no regressions. Mental and ACSpike also thought Launchpad sounded like a good option. Bulia and other heavy bug tracker users - can you give a thumbs up that this would be worth trying?
I'd welcome this so long as all the history of past bugs is not lost.
On Tue, Nov 06, 2007 at 10:54:42AM -0500, bulia byak wrote:
On 11/6/07, Bryce Harrington <bryce@...961...> wrote:
We've been wanting to switch from the extraordinarily painful SF bug tracker. Initially I thought we should host the service, but we don't have people with the expertise and time to do it, esp. given the DOS attack Inkscape suffered last week.
Ted, Kees, and I are investigating Launchpad, and think it will give all-around improvement with no regressions. Mental and ACSpike also thought Launchpad sounded like a good option. Bulia and other heavy bug tracker users - can you give a thumbs up that this would be worth trying?
I'd welcome this so long as all the history of past bugs is not lost.
Right, we asked about this and they confirmed that all bugs including all closed bugs will be imported, with status set accordingly.
Thanks, I'll go ahead with the next steps.
Bryce
participants (3)
-
Bryce Harrington -
bulia byak -
jiho