Since the topic came up, I thought I'd get the ball rolling. We need to figure out a few things in order to set up the SourceForge bug tracking.
Here are the menus that need to be set up for the Bug Tracker:
Categories Add categories like each directory in the base of the CVS: Framestein, abstractions, doc, externals, gem, htdocs, pd, xgui,(more?)
Group Add groups like, 'v0.36','extended','unsupported',','unverified', etc
Canned Response generic response messages for the tracker
Users for BugTracker i.e. people who can have bugs assigned to them (everyone?)
.hc
On Mon, 3 Mar 2003, Hans-Christoph Steiner wrote:
Since the topic came up, I thought I'd get the ball rolling. We need to figure out a few things in order to set up the SourceForge bug tracking.
Here are the menus that need to be set up for the Bug Tracker:
Categories Add categories like each directory in the base of the CVS: Framestein, abstractions, doc, externals, gem, htdocs, pd, xgui,(more?)
Group Add groups like, 'v0.36','extended','unsupported',','unverified', etc
Good initiative. I must admit that I do not really get the group entry. (In my mind group and category are somewhat synonymous).
I suggest therefore that we do not add groups, but only decide on the categories.
There is already a category "zexy", so we really might setup the categories in a way that the bug reports are directed to the original authors mainly. This means we will have lots of categories, which makes it more confusing to report bugs.
I think the categories you suggested are ok. (gem will be removed)
htdocs framestein externals abstractions doc pd
Maybe we can use the group entry to further specify the external category:
any zexy flext ggee maxlib ...
Canned Response generic response messages for the tracker
Yes, something like "Thank you for reporting a bug . blah blah ...."
Users for BugTracker i.e. people who can have bugs assigned to them (everyone?)
Yes, I think so. If anyone does not want to receive bugs, tell so. We could even think of sending them to the pd-dev list, but I think a lot of users are subscribed so it could generate unwanted additional traffic.
You are free to set this up, if it doesn't work out, we change it. Additionally we have to update the web site for CVS and document how to report a bug etc.
Guenter
guenter geiger said this at Tue, 4 Mar 2003 10:50:19 +0100:
Users for BugTracker i.e. people who can have bugs assigned to them (everyone?)
Yes, I think so. If anyone does not want to receive bugs, tell so. We could even think of sending them to the pd-dev list, but I think a lot of users are subscribed so it could generate unwanted additional traffic.
Okay, this part suggests another way of dividing things... it might be appropriate for some platform-specific categories(?). Frank (for example) might not want to be bothered by MacOSX bugs, while I might prefer to ignore Windows-based reports...
I know nothing about BugTracker... would this be possible?
adam
Using TCL as an example (http://sourceforge.net/tracker/?group_id=10894&atid=110894), they have about 80 Categories (Variables... dde package... http package) and the Groups are all version numbers. I think you can also use Groups to represent branches, i.e. pd from MSP and pd-extended (with CVS patches).
In the Tcl project, the Categories and Groups are quite specific. I think to do it like this, you need to have the developers re-categorizing and regrouping the bugs as they look through them. The bug submitter would be encouraged to take a guess, then whoever reviews the bug would change the Category and Group as they saw fit. I think this would be nice since you could really narrowly represent what that bug affected. Plus I think that it will be common that the developer will have to change the Category or Group that the bug was originally submitted under.
And yes, I think there could be platform-specific Categories for bugs that only affect that platform. But that means we might have to have duplicate categories for each platform, i.e. All GUIs, MacOS X GUI, Windows GUI, Linux GUI, etc.
.hc
On Tuesday, Mar 4, 2003, at 09:56 America/New_York, Adam Lindsay wrote:
guenter geiger said this at Tue, 4 Mar 2003 10:50:19 +0100:
Users for BugTracker i.e. people who can have bugs assigned to them (everyone?)
Yes, I think so. If anyone does not want to receive bugs, tell so. We could even think of sending them to the pd-dev list, but I think a lot of users are subscribed so it could generate unwanted additional traffic.
Okay, this part suggests another way of dividing things... it might be appropriate for some platform-specific categories(?). Frank (for example) might not want to be bothered by MacOSX bugs, while I might prefer to ignore Windows-based reports...
I know nothing about BugTracker... would this be possible?
adam
--
Adam T. Lindsay atl@comp.lancs.ac.uk Computing Dept, Lancaster University +44(0)1524/594.537 Lancaster, LA1 4YR, UK Fax:+44(0)1524/593.608 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Hans-Christoph Steiner said this at Tue, 4 Mar 2003 12:15:49 -0500:
In the Tcl project, the Categories and Groups are quite specific. I think to do it like this, you need to have the developers re-categorizing and regrouping the bugs as they look through them.
Ouch, I get the message. It turns from a convenient nicety into quite a heavy, organised operation. Sounds like something we want to avoid, at least at the start, right?
Also, I noticed that the MacOSX packages are available as downloads at sourceforge. Cool. Is there anything to unambiguously label them as being MacOSX or darwin or something? It's unclear until you go to the downloads page.
Cheers, adam
On Tuesday, Mar 4, 2003, at 12:33 America/New_York, Adam Lindsay wrote:
Hans-Christoph Steiner said this at Tue, 4 Mar 2003 12:15:49 -0500:
In the Tcl project, the Categories and Groups are quite specific. I think to do it like this, you need to have the developers re-categorizing and regrouping the bugs as they look through them.
Ouch, I get the message. It turns from a convenient nicety into quite a heavy, organised operation. Sounds like something we want to avoid, at least at the start, right?
Yeah, that's probably a good idea. Just a simple set to start with, to get people using the bug tracking, then as it progresses, a more complex setup if it suits us.
Also, I noticed that the MacOSX packages are available as downloads at sourceforge. Cool. Is there anything to unambiguously label them as being MacOSX or darwin or something? It's unclear until you go to the downloads page.
Good point. I'll rename the files.
.hc
Hallo, Adam Lindsay hat gesagt: // Adam Lindsay wrote:
Okay, this part suggests another way of dividing things... it might be appropriate for some platform-specific categories(?). Frank (for example) might not want to be bothered by MacOSX bugs, while I might prefer to ignore Windows-based reports...
But I want to ignore Windows-based reports, too! ;)
Now seriously, platform issues are sometimes hard to deal with. I'm regularly getting questions like "how to compile/use fiiwu~ on Windos", and in fact I don't know much about how to do this, so I'm refering those users to the list.
But those questions are not really bug reports. Or the bug is, that there are not binaries.
ciao
On Tue, 4 Mar 2003, Frank Barknecht wrote:
Hallo, Adam Lindsay hat gesagt: // Adam Lindsay wrote:
Okay, this part suggests another way of dividing things... it might be appropriate for some platform-specific categories(?). Frank (for example) might not want to be bothered by MacOSX bugs, while I might prefer to ignore Windows-based reports...
But I want to ignore Windows-based reports, too! ;)
Now seriously, platform issues are sometimes hard to deal with. I'm regularly getting questions like "how to compile/use fiiwu~ on Windos", and in fact I don't know much about how to do this, so I'm refering those users to the list.
But those questions are not really bug reports. Or the bug is, that there are not binaries.
At the beginning I do not think that we get too much bug reports, so we can scale up the thing later.
And then, I think it is important that everyone sees the bug messages from each platform. This is a cross platform project, and if someone changes his code on Linux which makes it crash on Windows, I think the person should know it, even if it works on his platform.
Well, just 2 cents ...
Guenter
guenter geiger said this at Tue, 4 Mar 2003 19:15:12 +0100:
And then, I think it is important that everyone sees the bug messages from each platform. This is a cross platform project, and if someone changes his code on Linux which makes it crash on Windows, I think the person should know it, even if it works on his platform.
Okay, point very well taken. :) In fact I started refuting myself once I brought Frank into the argument. :)
adam
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
And then, I think it is important that everyone sees the bug messages from each platform. This is a cross platform project, and if someone changes his code on Linux which makes it crash on Windows, I think the person should know it, even if it works on his platform.
Yes, of course. And I will try to support this kind of bug. I just cannot really test things on Windows, because I don't have the environment ready. I might try it, if the MinGW build is ready. Any news on this front? Can Pd be built without VisualC++ on Windows?
ciao
On Tue, 4 Mar 2003, Frank Barknecht wrote:
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
And then, I think it is important that everyone sees the bug messages from each platform. This is a cross platform project, and if someone changes his code on Linux which makes it crash on Windows, I think the person should know it, even if it works on his platform.
Yes, of course. And I will try to support this kind of bug. I just cannot really test things on Windows, because I don't have the environment ready. I might try it, if the MinGW build is ready. Any news on this front? Can Pd be built without VisualC++ on Windows?
Yes, it can. It just doesn't run yet :( I have built it once, but there are several #ifdefs in the code I have to fiddle with ... and then it costs so much time (and nerves) to reboot into windows.
I can try to integrate what I have done into the CVS.
I do not know yet if mingw externals and VisualC pd go together.
Guenter