Migration to SourceForge tracker? 🔗 link

On Mon, Aug 18, 2008 at 8:22 AM, SebA <user-7b2156f36779@xymon.invalid> 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

Date: Thu, 21 Aug 2008 20:07:21 -0400
From: user-98a0adc73677@xymon.invalid
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Migration to SourceForge tracker?

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 <user-7b2156f36779@xymon.invalid> 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 

On Fri, Aug 22, 2008 at 9:01 AM, T.J. Yang <user-8e841282cda5@xymon.invalid> wrote:

 If given voting right, I would vote for using trac to coordinate the
hobbit community.  sourcefoge looks like has a bigger supersets of features
than trac. I like the Statistics (R1) especially. Too bad we (hobbit
community) is not totally embraceing sourceforge.* *Ex, we still have our
own mailling list while sourceforge provide this feature.*

*I can work with either sourceforge or trac solutions, but please lets
utilize a solution's features as much as possible.*

• R1:
http://sourceforge.net/project/stats/detail.php?group_id=128058&ugn=hobbitmon&type=tracker

T.J. Yang

Date: Thu, 21 Aug 2008 20:07:21 -0400
From: user-98a0adc73677@xymon.invalid
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Migration to SourceForge tracker?


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 <user-7b2156f36779@xymon.invalid> 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


Be the filmmaker you always wanted to be—learn how to burn a DVD with

On Fri, Aug 22, 2008 at 10:11 AM, Ralph Mitchell <user-00a5e44c48c0@xymon.invalid>wrote:

One advantage of using Sourceforge is that they are hosting it.  Is there a
similar site hosting Trac??

Ralph Mitchell


On Fri, Aug 22, 2008 at 9:01 AM, T.J. Yang <user-8e841282cda5@xymon.invalid> wrote:

 If given voting right, I would vote for using trac to coordinate the
hobbit community.  sourcefoge looks like has a bigger supersets of features
than trac. I like the Statistics (R1) especially. Too bad we (hobbit
community) is not totally embraceing sourceforge.* *Ex, we still have our
own mailling list while sourceforge provide this feature.*

*I can work with either sourceforge or trac solutions, but please lets
utilize a solution's features as much as possible.*

• R1:
http://sourceforge.net/project/stats/detail.php?group_id=128058&ugn=hobbitmon&type=tracker

T.J. Yang

Date: Thu, 21 Aug 2008 20:07:21 -0400
From: user-98a0adc73677@xymon.invalid
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Migration to SourceForge tracker?


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 <user-7b2156f36779@xymon.invalid> 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


Be the filmmaker you always wanted to be—learn how to burn a DVD with
Windows(R). Make your smash hit<http://clk.atdmt.com/MRT/go/108588797/direct/01/>;

-- 

Date: Fri, 22 Aug 2008 09:11:31 -0500
From: user-00a5e44c48c0@xymon.invalid
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Migration to SourceForge tracker?

One advantage of using Sourceforge is that they are hosting it.  Is there a similar site hosting Trac??

Ralph Mitchell


On Fri, Aug 22, 2008 at 9:01 AM, T.J. Yang <user-8e841282cda5@xymon.invalid> wrote:


If given voting right, I would vote for using trac to coordinate the hobbit community.  sourcefoge looks like has a bigger supersets of features than trac. I like the Statistics (R1) especially. Too bad we (hobbit community) is not totally embraceing sourceforge. Ex, we still have our own mailling list while sourceforge provide this feature.


I can work with either sourceforge or trac solutions, but please lets utilize a solution's features as much as possible.


R1: http://sourceforge.net/project/stats/detail.php?group_id=128058&ugn=hobbitmon&type=tracker


T.J. Yang

Date: Thu, 21 Aug 2008 20:07:21 -0400
From: user-98a0adc73677@xymon.invalid
To: user-ae9b8668bcde@xymon.invalid

Subject: Re: [hobbit] Migration to SourceForge tracker?

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 <user-7b2156f36779@xymon.invalid> 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 

On Fri, Aug 22, 2008 at 11:02 AM, T.J. Yang <user-8e841282cda5@xymon.invalid> wrote:

 nope, there is no free trac hosting site to my knowledge.

T.J. Yang

Date: Fri, 22 Aug 2008 09:11:31 -0500
From: user-00a5e44c48c0@xymon.invalid

To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Migration to SourceForge tracker?

One advantage of using Sourceforge is that they are hosting it.  Is there a
similar site hosting Trac??

Ralph Mitchell


On Fri, Aug 22, 2008 at 9:01 AM, T.J. Yang <user-8e841282cda5@xymon.invalid> wrote:

 If given voting right, I would vote for using trac to coordinate the
hobbit community.  sourcefoge looks like has a bigger supersets of features
than trac. I like the Statistics (R1) especially. Too bad we (hobbit
community) is not totally embraceing sourceforge.* *Ex, we still have our
own mailling list while sourceforge provide this feature.*

*I can work with either sourceforge or trac solutions, but please lets
utilize a solution's features as much as possible.*

• R1:
http://sourceforge.net/project/stats/detail.php?group_id=128058&ugn=hobbitmon&type=tracker

T.J. Yang

Date: Thu, 21 Aug 2008 20:07:21 -0400
From: user-98a0adc73677@xymon.invalid
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Migration to SourceForge tracker?


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 <user-7b2156f36779@xymon.invalid> 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


Be the filmmaker you always wanted to be—learn how to burn a DVD with
Windows(R). Make your smash hit<http://clk.atdmt.com/MRT/go/108588797/direct/01/>;

On 8/22/2008 at 10:01 AM, "T.J. Yang" <user-8e841282cda5@xymon.invalid> wrote:

If given voting right, I would vote for using trac to coordinate the hobbit community.  sourcefoge looks like has a bigger supersets of features than trac. I like the Statistics (R1) especially. Too bad we (hobbit community) is not totally embraceing sourceforge. Ex, we still have our own mailling list while sourceforge provide this feature.

I can work with either sourceforge or trac solutions, but please lets utilize a solution's features as much as possible.

On Friday 22 August 2008 20:36:14 Jon Dustin wrote:

On 8/22/2008 at 10:01 AM, "T.J. Yang" <user-8e841282cda5@xymon.invalid> wrote:

If given voting right, I would vote for using trac to coordinate the
hobbit community.  sourcefoge looks like has a bigger supersets of
features than trac. I like the Statistics (R1) especially. Too bad we
(hobbit community) is not totally embraceing sourceforge.

???

Ex, we still
have our own mailling list while sourceforge provide this feature.

I can work with either sourceforge or trac solutions, but please lets
utilize a solution's features as much as possible.

Henrik has already spoken about Sourceforge mailing list, and has expressed
they are quite unreliable.

The existing mailing list works quite well for
us now, why not keep it as is?