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