Re: [hobbit] Migration to SourceForge tracker?

["Paul Ehrenreich" <paulehr (at) gmail.com>]

Instead of sourceforge, how about something like Trac?

http://trac.edgewall.org/

I think it has everything your looking for in a tracker, not to mention it
can integrate with subversion.

Another option would be if you don't want to host your own tracker is
Launchpad

https://launchpad.net/

Only issue with Launchpad is that it uses bazaar instead of subverison  for
a VCS.

-Paul


On Mon, Aug 18, 2008 at 8:22 AM, SebA <spa (at) syntec.co.uk> wrote:

>  Seeing as we are now using subversion (yay!), and moving to a more
> de-centralised development model, maybe it's time (or after the project
> namechange anyway) to start using the SourceForge bug and feature-request
> tracker?  (Or another tracker.)  This would enable all the developers and
> users to track the outstanding bugs instead of just Henrik.  I've noticed in
> the past that Henrik is very quick at fixing the critical bugs and core
> dumps (thanks), but other less critical ones (in trunk) seem to be
> outstanding for many months.  Having a public bug tracker would:
>
> (a) enable users to contribute to bugs via confirmation of the bug,
> narrowing down of the cause(s) / scenarios, testing of patches, etc.
>
> (b) ensure bugs (and feature requests) don't get forgotten about;
> (c) more easily allow other developers to create patches;
> (d) facilitate the release process by being able to see what might need
> fixing / doing / adding before the next release;  (I believe 4.3.0 is about
> a year overdue, but unfortunately trunk still isn't stable…)
>
> (e) increase the acceptance of Hobbit by users / companies, as it would
> increase the signs of life of the project (if used properly), the signs of
> support (in terms of bug fixing), etc.
>
> (f) encourage people posting bugs that someone who might fix their bug
> might (eventually) see their bug post! ;)
>
> In terms of the stability of hobbit, if new features are going to be added,
> isn't it time we branched 4.3 off from trunk?  (So we don't add new bugs to
> the 4.3 branch and further delay the release.  Or has this already been
> done?)  Personally, I would have liked this to have happened this time last
> year after Henrik announced 4.3.0 was nearly ready, instead of adding new
> features since then.  What would have happened, I suppose, is the current
> trunk would have developped into 4.4.0.  (If someone particularly wanted a
> specific new feature from trunk in 4.3, they could backport the patch.  This
> would be facilitated if patches were uploaded to the bug tracker for these
> new features when, or preferably before (thereby increasing the stability of
> trunk by allowing testing of the patch first), checking in to trunk.)  I
> expect nearly everyone knows an open-source project that works like this,
> but Asterisk is one that works well in this way, with hundreds of people
> submitting patches to their customised Mantis bug tracker.
>
> Kind regards,
>
> SebA
>
>