Hi,
I was thinking about sending the tracker information to a mailinglist, so that we all can monitor them, look at the bug reports, etc. etc.
IMO there are two options. One is to send all the tracker info to the pd-dev list, the other is to have separate lists like pd-bugs, pd-feature, pd-patches or one pd-tracker .... (well, its three options already).
Anyhow, in either case I think it would be best if the lists would be hosted by IEM (speaking set up by Johannes) just like the others. In case of using pd-dev directly, this list would have to be opened to noreply@sourceforge.net (thats where the tracker notification will be sent from).
Please let me know what you think about it.
Guenter
Its great that you set these up. A managable bug tracking system will be most helpful. As for the mailing lists, is it not possible for people to sign up for these mailings themselves via SourceForge? The extra mailing lists might still be a good idea tho, to provide a central place to register for this kind of info. I vote for three distinct mailing lists so you can choose which messages you want.
.hc
On Oct 20, 2004, at 6:32 AM, guenter geiger wrote:
Hi,
I was thinking about sending the tracker information to a mailinglist, so that we all can monitor them, look at the bug reports, etc. etc.
IMO there are two options. One is to send all the tracker info to the pd-dev list, the other is to have separate lists like pd-bugs, pd-feature, pd-patches or one pd-tracker .... (well, its three options already).
Anyhow, in either case I think it would be best if the lists would be hosted by IEM (speaking set up by Johannes) just like the others. In case of using pd-dev directly, this list would have to be opened to noreply@sourceforge.net (thats where the tracker notification will be sent from).
Please let me know what you think about it.
Guenter
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Wed, 20 Oct 2004, Hans-Christoph Steiner wrote:
Its great that you set these up.
Well, they were set up from the beginning, I am just trying to promote them actually. SF documentation says that one could monitor each of these trackers, but I couldn't find the button to turn that on, thats why I thought mailing list would be nice too. Anyhow, if Johannes doesn't want to manage the mailing lists I am going to set them up on sourceforge. Probably that would be the easiest thing in terms of maintenance, and this way Johannes doesn't have the additional work.
Three distinct lists is probably the best solution.
Guenter
A managable bug tracking system will be most helpful. As for the mailing lists, is it not possible for people to sign up for these mailings themselves via SourceForge? The extra mailing lists might still be a good idea tho, to provide a central place to register for this kind of info. I vote for three distinct mailing lists so you can choose which messages you want.
.hc
On Oct 20, 2004, at 6:32 AM, guenter geiger wrote:
Hi,
I was thinking about sending the tracker information to a mailinglist, so that we all can monitor them, look at the bug reports, etc. etc.
IMO there are two options. One is to send all the tracker info to the pd-dev list, the other is to have separate lists like pd-bugs, pd-feature, pd-patches or one pd-tracker .... (well, its three options already).
Anyhow, in either case I think it would be best if the lists would be hosted by IEM (speaking set up by Johannes) just like the others. In case of using pd-dev directly, this list would have to be opened to noreply@sourceforge.net (thats where the tracker notification will be sent from).
Please let me know what you think about it.
Guenter
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
http://at.or.at/hans/
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
On Wed, 20 Oct 2004, Hans-Christoph Steiner wrote:
Its great that you set these up.
Well, they were set up from the beginning, I am just trying to promote them actually. SF documentation says that one could monitor each of these trackers, but I couldn't find the button to turn that on,
I think, you can only monitor individual items. But I didn't find the button 'Click on the "Monitor Project" link, located below the project description, to begin monitoring of the project.' as well. :( Although I am monitoring the two Feature Request I submitted.
Anyhow, if Johannes doesn't want to manage the mailing lists I am going to set them up on sourceforge. Probably that would be the easiest thing in terms of maintenance, and this way Johannes doesn't have the additional work.
Three distinct lists is probably the best solution.
I wouldn't have a problem with all tracker mails ending up here on pd-dev. Many dev-lists I'm on do this, e.g. alsa-devel.
Ciao
On Thu, 21 Oct 2004, Frank Barknecht wrote:
I think, you can only monitor individual items. But I didn't find the button 'Click on the "Monitor Project" link, located below the project description, to begin monitoring of the project.' as well.
Good to hear that you had the same problem. So its not only me.
Guenter
I am monitoring the two Feature Request I submitted.
Anyhow, if Johannes doesn't want to manage the mailing lists I am going to set them up on sourceforge. Probably that would be the easiest thing in terms of maintenance, and this way Johannes doesn't have the additional work.
Three distinct lists is probably the best solution.
I wouldn't have a problem with all tracker mails ending up here on pd-dev. Many dev-lists I'm on do this, e.g. alsa-devel.
Ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Frank Barknecht schrieb:
Well, they were set up from the beginning, I am just trying to promote them actually. SF documentation says that one could monitor each of these trackers, but I couldn't find the button to turn that on,
I think, you can only monitor individual items. But I didn't find the button 'Click on the "Monitor Project" link, located below the project description, to begin monitoring of the project.' as well. :( Although I am monitoring the two Feature Request I submitted.
As "admin" (on sf.net) you can do that, as "developer" or "user" only individual items. I do so for my project.
Anyhow, if Johannes doesn't want to manage the mailing lists I am going to set them up on sourceforge. Probably that would be the easiest thing in terms of maintenance, and this way Johannes doesn't have the additional work.
Three distinct lists is probably the best solution.
I wouldn't have a problem with all tracker mails ending up here on pd-dev. Many dev-lists I'm on do this, e.g. alsa-devel.
There are a couple of things that do need to be set up:
In these three sections (Bugs, Support, and Patches), we need to come up with a list of Categories and Groups. There are already some Categories, we can try those out and see how they work. I took a look at some other SourceForge project to see what kind of Categories they used. It seems that most people use the categories to label what kind of problem it is rather than which part of the code it is in, things like "Authentication Issues" or "Internationalization" (phpMyAdmin); or "Crash/Runtime error" (Fink). Groups seem to be version numbers (0.37-2, 0.37-devel, etc.). Here are some quick ideas for some Categories for Pd:
Bugs Crashers Hardware Support (sound cards, OpenGL, etc.) Audio Problems Video Problems MacOS X packaging Windows Installer Debian Packages Patches MSP Core devel_0_37 externals doc
As for the Support section, I think we shouldn't use it, unless we have volunteers who are willing to check up on Support tickets, I think we should try to focus all such requests to the list and start maintaining the FAQ. Having a forum interface to the lists would be awesome for those who don't want to join the lists.
.hc
On Oct 21, 2004, at 3:24 AM, guenter geiger wrote:
On Wed, 20 Oct 2004, Hans-Christoph Steiner wrote:
Its great that you set these up.
Well, they were set up from the beginning, I am just trying to promote them actually. SF documentation says that one could monitor each of these trackers, but I couldn't find the button to turn that on, thats why I thought mailing list would be nice too. Anyhow, if Johannes doesn't want to manage the mailing lists I am going to set them up on sourceforge. Probably that would be the easiest thing in terms of maintenance, and this way Johannes doesn't have the additional work.
Three distinct lists is probably the best solution.
Guenter
A managable bug tracking system will be most helpful. As for the mailing lists, is it not possible for people to sign up for these mailings themselves via SourceForge? The extra mailing lists might still be a good idea tho, to provide a central place to register for this kind of info. I vote for three distinct mailing lists so you can choose which messages you want.
.hc
On Oct 20, 2004, at 6:32 AM, guenter geiger wrote:
Hi,
I was thinking about sending the tracker information to a mailinglist, so that we all can monitor them, look at the bug reports, etc. etc.
IMO there are two options. One is to send all the tracker info to the pd-dev list, the other is to have separate lists like pd-bugs, pd-feature, pd-patches or one pd-tracker .... (well, its three options already).
Anyhow, in either case I think it would be best if the lists would be hosted by IEM (speaking set up by Johannes) just like the others. In case of using pd-dev directly, this list would have to be opened to noreply@sourceforge.net (thats where the tracker notification will be sent from).
Please let me know what you think about it.
Guenter
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
http://at.or.at/hans/
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Here are some quick ideas for some Categories for Pd:
Bugs Crashers Hardware Support (sound cards, OpenGL, etc.) Audio Problems Video Problems MacOS X packaging Windows Installer Debian Packages
I think the last three would be better described as
OS-specific issues: Windows OS-X Linux (Debian has its own BTS.) Others
Also bugs in "Abstractions" are needed.
Patches MSP Core devel_0_37
IMO, devel should loose its version number suffix. Everywhere. ;)
externals doc
Maybe "Abstractions"?? They are hard to patch, though.
Ciao
On Thu, 21 Oct 2004, Frank Barknecht wrote:
Patches MSP Core devel_0_37
IMO, devel should loose its version number suffix. Everywhere. ;)
There is a devel_0_35, devel_0_36 too, there might be a devel_0_38. The version numbers do have a very good reason in CVS, because the development model of pd is not the same as in other free software projects. The development branch does not become automatically the stable one. Having different tags depending on the versions helps to identify the changes.
.. but probably thats not what you meant with "everywhere" :)
Guenter
externals doc
Maybe "Abstractions"?? They are hard to patch, though.
Ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
On Thu, 21 Oct 2004, Frank Barknecht wrote:
Patches MSP Core devel_0_37
IMO, devel should loose its version number suffix. Everywhere. ;)
There is a devel_0_35, devel_0_36 too, there might be a devel_0_38. The version numbers do have a very good reason in CVS, because the development model of pd is not the same as in other free software projects. The development branch does not become automatically the stable one.
But it does become the next devel branch eventually.
Having different tags depending on the versions helps to identify the changes.
I still don't get the reason for having a "devel_version" branch. IMO the main "devel" branch should be just that, a "devel" branch, which should be as current and experimental as possible.
I don't see why anyone would still need to work on a "devel_0_36" branch? 0_36 is obsolete. The same will happen to "devel_0_37", when a "devel_0_38" is created. The advantage of having one consistently named "devel"-banch is, that I wouldn't need to change my "cvs co" options with every new release. Also it would make clearer, that "devel" is a different, but somehow parallel evolution of some "MAIN" branch.
What I would prefer: Before "devel" is brought up to the next MAIN version, there should be a "freeze" of "devel" into "devel_XX". Then changes from MAIN would get incorporated and "devel" would still be "devel", just an updated one.
Anyway, this is just my opinion, and you shouldn't take this as too important, as I don't work directly on Pd-core, and in no way do I intend to force my preferences onto anybody else.
However I do think, that a section for patches in the patch tracker should not mention the version number, as this will make the handling of patches - which are date-dependent anyway - harder: We would need to add a tracker for every devel_X release.
Ciao
On Thu, 21 Oct 2004, Frank Barknecht wrote:
projects. The development branch does not become automatically the stable one.
But it does become the next devel branch eventually.
I always thought about that in a different way. I didn't merge Millers changes into the devel branch but the other way round. But you surely know better :)
Having different tags depending on the versions helps to identify the changes.
I still don't get the reason for having a "devel_version" branch. IMO the main "devel" branch should be just that, a "devel" branch, which should be as current and experimental as possible.
And if the only reason is that we are accostumed to it ? I would still like to hear a convincing reason why we should switch to devel, and why it matters.
I don't see why anyone would still need to work on a "devel_0_36" branch? 0_36 is obsolete. The same will happen to "devel_0_37", when a "devel_0_38" is created. The advantage of having one consistently named "devel"-banch is, that I wouldn't need to change my "cvs co" options with every new release. Also it would make clearer, that "devel" is a different, but somehow parallel evolution of some "MAIN" branch.
Currently the naming makes clear that devel_0_XX is a branched version of a stable release (version XX). This helps me to keep track where we are, and tells the people who want to try the CVS version were we are. E.g. now, if you download CVS you know were it stands immediately.
If it would be called "devel" only, people would think it is the newer and better version of 0.38, which it isn't.
What I would prefer: Before "devel" is brought up to the next MAIN version, there should be a "freeze" of "devel" into "devel_XX". Then changes from MAIN would get incorporated and "devel" would still be "devel", just an updated one.
Anyway, this is just my opinion, and you shouldn't take this as too important, as I don't work directly on Pd-core, and in no way do I intend to force my preferences onto anybody else.
Everyones opinion is important here :). But you are right, noone can force anything. We're all dependent on good will.
However I do think, that a section for patches in the patch tracker should not mention the version number, as this will make the handling of patches - which are date-dependent anyway - harder: We would need to add a tracker for every devel_X release.
I tried to make that clear in the description at http://pure-data.sourceforge.net/bug-report.php The patches are against Millers version, in order to make it easier for him to incorporate changes. I am going to rephrase it to make it clearer.
Guenter
Ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Frank Barknecht wrote:
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
I don't see why anyone would still need to work on a "devel_0_36" branch? 0_36 is obsolete. The same will happen to "devel_0_37", when a
i would not second this. i am not working with the "devel"-branch but only with miller's official (test)releases (and sometimes some minor modifications by me) there *are* things that work only work (correctly) with older versions of pd (just yesterday, i stumbled over one of these); the same will most probably be true for the devel-branch.
mfg.a.sdr IOhannes
Hallo, Johannes M Zmoelnig hat gesagt: // Johannes M Zmoelnig wrote:
i am not working with the "devel"-branch but only with miller's official (test)releases (and sometimes some minor modifications by me) there *are* things that work only work (correctly) with older versions of pd (just yesterday, i stumbled over one of these); the same will most probably be true for the devel-branch.
I doubt, that the same is true for devel, though. Nevertheless by proper tagging (and even without by checking out dates), getting older versions from CVS is always possible.
Ciao
devel_0_37
IMO, devel should loose its version number suffix. Everywhere. ;)
i don't think so ...
at the moment there will be a new devel_xxx branch for every release ... that makes porting a LOT easier ... e.g. now that miller worked on the gui, we might not need the threaded gui patch by yves any more ... and since most of the major changes (at least mine) in the devel branch are defined in "#ifdef"s, it's easier to merge them into the new msp branch, than the msp branch to the devel ...
cheers ... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
at the moment there will be a new devel_xxx branch for every release ... that makes porting a LOT easier ... e.g. now that miller worked on the gui, we might not need the threaded gui patch by yves any more ... and since most of the major changes (at least mine) in the devel branch are defined in "#ifdef"s, it's easier to merge them into the new msp branch, than the msp branch to the devel ...
But would this be any different, if the name of "devel_0_37" was "devel"?
Ciao
On Thu, 21 Oct 2004, Hans-Christoph Steiner wrote:
There are a couple of things that do need to be set up:
In these three sections (Bugs, Support, and Patches), we need to come up with a list of Categories and Groups. There are already some Categories, we can try those out and see how they work. I took a look at some other SourceForge project to see what kind of Categories they used. It seems that most people use the categories to label what kind of problem it is rather than which part of the code it is in, things like "Authentication Issues" or "Internationalization" (phpMyAdmin); or "Crash/Runtime error" (Fink). Groups seem to be version numbers (0.37-2, 0.37-devel, etc.). Here are some quick ideas for some
I have added some Categories (I took the categories because this was the tab that is on the submit page).
They are currently: zexy puredata-dev puredata externals abstractions
I am not sure if we need two qualifiers. It is important to have distinct reports for puredata, the externals, etc.
We could add flext, cyclone, maxlib, iemlib etc,
One big advantage in categorizing with sub projects is that it is orthogonal. This is hard to do with other more abstract categories (should I file a bug report against hardware support, audio problems or the MaxOS X package if pd only runs with -noadc on my machine ?) Lets make bug reporting not too difficult at the beginning. If we need more structure we can add it later.
Categories for Pd:
Bugs Crashers Hardware Support (sound cards, OpenGL, etc.) Audio Problems Video Problems MacOS X packaging Windows Installer Debian Packages
Patches MSP Core devel_0_37 externals doc
The patches are mainly thought to be against Pd. This should be a collection of suggestions, easily browsable, mainly to facilitate the incorporation of features from the development branch.
We actually shouldn't need patches against the development branch. Categorization is basically the same as with bugs.
As for the Support section, I think we shouldn't use it, unless we have volunteers who are willing to check up on Support tickets, I think we should try to focus all such requests to the list and start maintaining the FAQ. Having a forum interface to the lists would be awesome for those who don't want to join the lists.
I agree that the support section is what the list should be about. Personally I am not missing a forum, others might find it useful though. A good FAQ is something that should be worked out at the puredata.org site.
Guenter
.hc
On Oct 21, 2004, at 3:24 AM, guenter geiger wrote:
On Wed, 20 Oct 2004, Hans-Christoph Steiner wrote:
Its great that you set these up.
Well, they were set up from the beginning, I am just trying to promote them actually. SF documentation says that one could monitor each of these trackers, but I couldn't find the button to turn that on, thats why I thought mailing list would be nice too. Anyhow, if Johannes doesn't want to manage the mailing lists I am going to set them up on sourceforge. Probably that would be the easiest thing in terms of maintenance, and this way Johannes doesn't have the additional work.
Three distinct lists is probably the best solution.
Guenter
A managable bug tracking system will be most helpful. As for the mailing lists, is it not possible for people to sign up for these mailings themselves via SourceForge? The extra mailing lists might still be a good idea tho, to provide a central place to register for this kind of info. I vote for three distinct mailing lists so you can choose which messages you want.
.hc
On Oct 20, 2004, at 6:32 AM, guenter geiger wrote:
Hi,
I was thinking about sending the tracker information to a mailinglist, so that we all can monitor them, look at the bug reports, etc. etc.
IMO there are two options. One is to send all the tracker info to the pd-dev list, the other is to have separate lists like pd-bugs, pd-feature, pd-patches or one pd-tracker .... (well, its three options already).
Anyhow, in either case I think it would be best if the lists would be hosted by IEM (speaking set up by Johannes) just like the others. In case of using pd-dev directly, this list would have to be opened to noreply@sourceforge.net (thats where the tracker notification will be sent from).
Please let me know what you think about it.
Guenter
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
http://at.or.at/hans/
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
�El pueblo unido jam�s ser� vencido!
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
-
Frank Barknecht -
guenter geiger -
Hans-Christoph Steiner -
Johannes M Zmoelnig -
Reini Urban -
Tim Blechmann