hi all,
On Thu, 15 Dec 2005 12:00:37 +0100 pd-cvs-request@iem.at wrote:
Log Message: checking in missing files on behalf of Miller (cleared it with him first). The files are from portmidi17nov04.zip
great ... i'm trying to remove all external sources from the cvs ... and the portmidi sources are added ...
t
On Dec 15, 2005, at 11:46 AM, Tim Blechmann wrote:
hi all,
On Thu, 15 Dec 2005 12:00:37 +0100 pd-cvs-request@iem.at wrote:
Log Message: checking in missing files on behalf of Miller (cleared it with him first). The files are from portmidi17nov04.zip
great ... i'm trying to remove all external sources from the cvs ... and the portmidi sources are added ...
I am just making the CVS a mirror of Miller's development environment, the portmidi and portaudio stuff was half-complete, so it makes more sense to have it complete then leave it as is. Previously, it was missing files which were used in the compilation.
I've been posting on this topic for a while now, so it shouldn't be a surprise. I just finally got around to acting on it.
.hc
t
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
If you are not part of the solution, you are part of the problem.
- Eldridge Cleaver
On Thu, 15 Dec 2005 18:42:15 -0500 Hans-Christoph Steiner hans@eds.org wrote:
On Dec 15, 2005, at 11:46 AM, Tim Blechmann wrote:
hi all,
On Thu, 15 Dec 2005 12:00:37 +0100 pd-cvs-request@iem.at wrote:
Log Message: checking in missing files on behalf of Miller (cleared it with him first). The files are from portmidi17nov04.zip
great ... i'm trying to remove all external sources from the cvs ... and the portmidi sources are added ...
I am just making the CVS a mirror of Miller's development environment, the portmidi and portaudio stuff was half-complete, so it makes more sense to have it complete then leave it as is. Previously, it was missing files which were used in the compilation.
I've been posting on this topic for a while now, so it shouldn't be a surprise. I just finally got around to acting on it.
i read your previous mails ... still i think, that the people, who would like to compile pd are capable of downloading one or two dependencies (if they're not the can use the binaries) and that it's far better to try to stay in sync with the upstream of these specific packages ... (see the portaudio memory leak on osx a few weeks ago)
tim
On Dec 15, 2005, at 7:50 PM, Tim Blechmann wrote:
On Thu, 15 Dec 2005 18:42:15 -0500 Hans-Christoph Steiner hans@eds.org wrote:
On Dec 15, 2005, at 11:46 AM, Tim Blechmann wrote:
hi all,
On Thu, 15 Dec 2005 12:00:37 +0100 pd-cvs-request@iem.at wrote:
Log Message: checking in missing files on behalf of Miller (cleared it with him first). The files are from portmidi17nov04.zip
great ... i'm trying to remove all external sources from the cvs ... and the portmidi sources are added ...
I am just making the CVS a mirror of Miller's development environment, the portmidi and portaudio stuff was half-complete, so it makes more sense to have it complete then leave it as is. Previously, it was missing files which were used in the compilation.
I've been posting on this topic for a while now, so it shouldn't be a surprise. I just finally got around to acting on it.
i read your previous mails ... still i think, that the people, who would like to compile pd are capable of downloading one or two dependencies (if they're not the can use the binaries) and that it's far better to try to stay in sync with the upstream of these specific packages ... (see the portaudio memory leak on osx a few weeks ago)
Staying in sync sounds good to me. But I think that since portaudio/portmidi are not stable APIs and still alpha/beta code, we should maintain a copy in CVS. That way, when we get a version that we know works, we can have it in CVS, and Pd will always build. And when someone new comes along, they won't have to deal with tracking down the right CVS snapshot for getting Pd to compile/run stably.
And its easy enough for devs to point to the portaudio/portmidi source of their choosing, just change -I../portaudio to whatever you want.
.hc
tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
Staying in sync sounds good to me. But I think that since portaudio/portmidi are not stable APIs and still alpha/beta code, we should maintain a copy in CVS.
portaudio/midi is fairly stable and not under particularly active development now that it supports everything people actually use like coreaudio alsa and mme/ds/asio - i wouldnt classify it under alpha/beta status even v19.. anyways it's a seperate project and should not be in the pure-data CVS, it has its own..
for PD, i suggest we move to darcs. it seems particularly well suited to the current situation where each developer more or less has their own version, may ease intra-branch feature stealing/merging and its underlying theory may even satisfy the sourceforge-patch-tracker fetishists:
(from http://osdir.com/Article2571.phtml )David Roundy: At its most basic level, the theory of patches is about the commutation, or reordering, of changes in such a way that their meaning doesn't change. Once the commutation primitives have been worked out, one can do all sorts of interesting (and useful) operations, such as merging. And such operations can be shown to be independent of order, i.e. it doesn't matter whether you merge patch A or patch B first, you'll get the same result. Another result of the design based on inexact patching is that you can, for example, cherrypick a change that modifies a file without first getting the change that *creates* the file
the "Theory of Patches" is described in further detail @ http://abridgegame.org/darcs/manual/node8.html
Staying in sync sounds good to me. But I think that since portaudio/portmidi are not stable APIs and still alpha/beta code, we should maintain a copy in CVS.
what? the portaudio api's 1 and 2 are perfectly defined, there is absolute no need to keep a copy ...
portaudio/midi is fairly stable and not under particularly active development now that it supports everything people actually use like coreaudio alsa and mme/ds/asio - i wouldnt classify it under alpha/beta status even v19.. anyways it's a seperate project and should not be in the pure-data CVS, it has its own..
don't agree either ... portaudio is still under development ... portaudio v19 isn't fully implemented, yet ... but if you classify pd to be late alpha, then portaudio 19 is late beta ...
in any case ... if we keep the portaudio/midi sources in the cvs, i'd propose to add the alsa and the jack sources, too. of course the next step would be to add the asio-sdk, which would result in some legal problems, but you can't build pd with portaudio/asio on windoze without this sdk...
t
On Dec 16, 2005, at 4:28 AM, Tim Blechmann wrote:
Staying in sync sounds good to me. But I think that since portaudio/portmidi are not stable APIs and still alpha/beta code, we should maintain a copy in CVS.
what? the portaudio api's 1 and 2 are perfectly defined, there is absolute no need to keep a copy ...
That is far from the only reason to keep a copy in
portaudio/midi is fairly stable and not under particularly active development now that it supports everything people actually use like coreaudio alsa and mme/ds/asio - i wouldnt classify it under alpha/beta status even v19.. anyways it's a seperate project and should not be in the pure-data CVS, it has its own..
don't agree either ... portaudio is still under development ... portaudio v19 isn't fully implemented, yet ... but if you classify pd to be late alpha, then portaudio 19 is late beta ...
Show me a release. A CVS snapshot is not a release. The portaudio people apparently think its not beta yet since there is no release. I'll take their word for it.
In any case ... if we keep the portaudio/midi sources in the cvs, i'd propose to add the alsa and the jack sources, too. of course the next step would be to add the asio-sdk, which would result in some legal problems, but you can't build pd with portaudio/asio on windoze without this sdk...
It would be good to have ASIO in there, but yes, the license does not allow it. As for Jack and ALSA, there are releases. ALSA is past 1.0, so its silly to compare it. Plus, I think that the Debian, RedHat, Fink, etc. etc. packages work much better than keeping the source in CVS. You cannot get portaudio 19 packages from Debian, RedHat or Fink (though perhaps from other sources).
.hc
________________________________________________________________________ ____
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
Staying in sync sounds good to me. But I think that since portaudio/portmidi are not stable APIs and still alpha/beta code, we should maintain a copy in CVS.
what? the portaudio api's 1 and 2 are perfectly defined, there is absolute no need to keep a copy ...
That is far from the only reason to keep a copy in
and i stated my arguments ...
this discussion won't have a solution ... do whatever you want with miller's pd ... i don't care if you check in the latest pa12 release or whatever ... pd has bigger problems, than the placement of external sources ...
just keep all external sources out of devel ...
t
On Dec 16, 2005, at 1:57 PM, Tim Blechmann wrote:
Staying in sync sounds good to me. But I think that since portaudio/portmidi are not stable APIs and still alpha/beta code, we should maintain a copy in CVS.
what? the portaudio api's 1 and 2 are perfectly defined, there is absolute no need to keep a copy ...
That is far from the only reason to keep a copy in
and i stated my arguments ...
this discussion won't have a solution ... do whatever you want with miller's pd ... i don't care if you check in the latest pa12 release or whatever ... pd has bigger problems, than the placement of external sources ...
just keep all external sources out of devel ...
This is exactly the reason why I am unwilling to work on pd-devel. I have spent far too long on build systems and creating cross-platform packages that actually work. I have yet to see a downloadable binary that works for pd-devel since I stopped doing it at devel_0_37. I have zero interest in applying my knowledge when all I get in return is hostility. But its all free software, so feel free to do so yourself.
The bottom line is that the Pd source code is messy, we all know that. And we have to live with it. Its a big project, there are dozens of developers, so change is inevitably slow. But personally I think that getting our code out to people who want to use it is actually very important, and I am willing to compromise in other things in order to achieve that.
.hc
t
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
This is exactly the reason why I am unwilling to work on pd-devel. I have spent far too long on build systems and creating cross-platform packages that actually work. I have yet to see a downloadable binary that works for pd-devel since I stopped doing it at devel_0_37. I have zero interest in applying my knowledge when all I get in return is hostility. But its all free software, so feel free to do so yourself.
i can't follow this point ... it's perfectly possible to write a script in your favorite scripting language that downloads external sources decompresses and installs them (maybe not asiosdk, since it's proprietary)...
scons e.g. offers the possibility to download sources directly from a cvs / svn / bitkeeper repository ... if you want to implement a 1-click solution, this would be the easiest way to go ... but i know, you dislike scons, it's possible to do that in each other scripting language ... possibly you can even implement this with pd ...
t
On Dec 16, 2005, at 4:53 PM, Tim Blechmann wrote:
This is exactly the reason why I am unwilling to work on pd-devel. I have spent far too long on build systems and creating cross-platform packages that actually work. I have yet to see a downloadable binary that works for pd-devel since I stopped doing it at devel_0_37. I have zero interest in applying my knowledge when all I get in return is hostility. But its all free software, so feel free to do so yourself.
i can't follow this point ... it's perfectly possible to write a script in your favorite scripting language that downloads external sources decompresses and installs them (maybe not asiosdk, since it's proprietary)...
Sure, I've done that, checkout scripts/checkout-developer-layout.sh. But that does not help one bit when deciding _which version_ of portaudio to download, there is no released version of 19. I suppose you could add the date tag to the script, but then you are building a code management system from scratch. And that makes no sense to me when we are already using CVS, which is far better code management software than any script that any of us are going to write.
scons e.g. offers the possibility to download sources directly from a cvs / svn / bitkeeper repository ... if you want to implement a 1-click solution, this would be the easiest way to go ... but i know, you dislike scons, it's possible to do that in each other scripting language ... possibly you can even implement this with pd ...
I have no problem with scons. But I have never written a conf file for scons, or used python for that matter, so I can't say a lot. I think that is the case for the large majority of the Pd developers. My first impression of scons is that its much slower than configure/make, probably because it does a lot of stuff automatically. From my perspective, this really sucks when having to tweak the Pd-extended build on three different computers.
In a fresh CVS checkout of 0.38.4, autoconf && ./configure && make took a total of 34 seconds.
In a fresh CVS checkotu of pd devel_0_38, after waiting 14 minutes, 8 seconds, I got this:
src/t_main.c:18:16: tk.h: No such file or directory src/t_main.c:38: error: syntax error before '*' token src/t_main.c: In function `main': src/t_main.c:59: error: `Tcl_AppInit' undeclared (first use in this function) src/t_main.c:59: error: (Each undeclared identifier is reported only once src/t_main.c:59: error: for each function it appears in.) src/t_main.c: At top level: src/t_main.c:86: error: syntax error before "Tcl_Interp" src/t_main.c:86: warning: data definition has no type or storage class src/t_main.c:87: error: syntax error before '{' token src/t_main.c:99: warning: parameter names (without types) in function declaration src/t_main.c:99: error: conflicting types for `pdgui_startup' src/t_main.c:38: error: previous declaration of `pdgui_startup' src/t_main.c:99: warning: data definition has no type or storage class src/t_main.c:112: error: syntax error before "return" scons: *** [src/t_main.o] Error 1 scons: building terminated because of errors.
Make is old and a bit whacked, that I know, but it works everywhere, basically any C developer can open up a Makefile and parse it. For the most part, its just lines you'd type into the shell. Make is also been around a long time and the bugs have long since been worked out. Plus there is decades of documentation, group and list posts, examples, etc. to learn from. scons is at version 0.96, and they are still catching critical bugs.
scons sounds promising, I hope it gets better, and it probably handles complicated builds better than make. But Pd really should not be complicated to build. The complications are almost all because everyone wants to do everything their own way. I encourage everyone to experiment with things like scons, svn, or whatever you want to. But I propose we keep Pd a place to experiment with sound processing, media, realtime systems, etc.
Then when the critical bugs are ironed out with scons, and its progressed passed 1.0, and people have written nice Makefile conversion scripts, it could be worth the effort of all 40+ of us relearning a new build system, and many of us learning a new language to boot.
.hc
t
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
________________________________________________________________________ ____
If you are not part of the solution, you are part of the problem.
- Eldridge Cleaver
On Fri, 16 Dec 2005, Hans-Christoph Steiner wrote:
My first impression of scons is that its much slower than configure/make, probably because it does a lot of stuff automatically. From my perspective, this really sucks when having to tweak the Pd-extended build on three different computers. In a fresh CVS checkout of 0.38.4, autoconf && ./configure && make took a total of 34 seconds. In a fresh CVS checkotu of pd devel_0_38, after waiting 14 minutes, 8 seconds, I got this:
I have a problem with scons, in that it tries to scan a lot of directories it shouldn't scan, especially all of $HOME recursively if you use prefix=$HOME (or all of /usr if you use prefix=/usr). I think that this is the most annoying thing with scons. I think I've had other problems with it but I don't recall what they were.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
I have a problem with scons, in that it tries to scan a lot of directories it shouldn't scan, especially all of $HOME recursively if you use prefix=$HOME (or all of /usr if you use prefix=/usr). I think that this is the most annoying thing with scons. I think I've had other problems with it but I don't recall what they were.
iirc i've adapted the scons script ...
t
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
i can't follow this point ... it's perfectly possible to write a script in your favorite scripting language that downloads external sources decompresses and installs them (maybe not asiosdk, since it's proprietary)...
You can't build a Debian package this way, or any other package, that also includes the possibility to be rebuilt without net connection.
Ciao
On Fri, 16 Dec 2005, Hans-Christoph Steiner wrote:
The bottom line is that the Pd source code is messy, we all know that. And we have to live with it. Its a big project, there are dozens of developers, so change is inevitably slow.
I'd like you to substantiate that claim. There may be dozens of registered developers, but how many modify the "pd" module? and how many modify "pd/src" ?
My impression is that there is not enough people working on "pd/src" and that this is because the development/release process doesn't encourage developers to join the project.
But personally I think that getting our code out to people who want to use it is actually very important,
I agree.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hi all,
On Dec 15, 2005, at 11:46 AM, Tim Blechmann wrote:
hi all,
On Thu, 15 Dec 2005 12:00:37 +0100 pd-cvs-request@iem.at wrote:
Log Message: checking in missing files on behalf of Miller (cleared it with him first). The files are from portmidi17nov04.zip
great ... i'm trying to remove all external sources from the cvs ... and the portmidi sources are added ...
i think it's no secret that i'm also against keeping the sources inside the pd cvs. I already proposed that more than once. To my mind it's a source for confusion and it's unnecessary duplication of resources. The usage of the original PA-sources will lead to faster propagation of improvements into PD and will finally save us from the PA and PM folder chaos that has been present in the CVS for too long already.
greetings, Thomas
On Dec 16, 2005, at 12:44 PM, Thomas Grill wrote:
Hi all,
On Dec 15, 2005, at 11:46 AM, Tim Blechmann wrote:
hi all,
On Thu, 15 Dec 2005 12:00:37 +0100 pd-cvs-request@iem.at wrote:
Log Message: checking in missing files on behalf of Miller (cleared it with him first). The files are from portmidi17nov04.zip
great ... i'm trying to remove all external sources from the cvs ... and the portmidi sources are added ...
i think it's no secret that i'm also against keeping the sources inside the pd cvs. I already proposed that more than once. To my mind it's a source for confusion and it's unnecessary duplication of resources. The usage of the original PA-sources will lead to faster propagation of improvements into PD and will finally save us from the PA and PM folder chaos that has been present in the CVS for too long already.
For released software, this makes a lot of sense. Not so for alpha software like portaudio/midi. The setup you describe works fine for developers, we all know how to make the compilation find the sources we want.
But the key points that you are overlooking is package building and auto-building. For example, the Debian auto-builders are not going to add some tarball because we want them to. There are no packages for portaudio 19 from RedHat, Debian, or Fink (let alone MinGW or MSVC). When looking at this, keeping these sources out of our CVS quite simply creates a lot of manual labor that is boring and annoying at best.
Importing external sources is a common practice, and the CVS manual even covers the topic. CVS allows us to manage source code, no matter who wrote it. I really dread the thought of handling this manually, which is what you are proposing.
.hc
________________________________________________________________________ ____
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously.
- Benjamin Franklin
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
But the key points that you are overlooking is package building and auto-building. For example, the Debian auto-builders are not going to add some tarball because we want them to. There are no packages for portaudio 19 from RedHat, Debian, or Fink (let alone MinGW or MSVC). When looking at this, keeping these sources out of our CVS quite simply creates a lot of manual labor that is boring and annoying at best.
I agree here, not only because I am a Debian user, but Debian is a good example for the problem at hand: Debian has packages for portaudio 0.18, no packages for whatever is considered to be PA 0.19 and Debian's portmidi is from 2004-11-17.
So for doing Debian packages of Pd we could either elect someone to create portaudio packages that match our needs, or we'd need to make Pd run with PA 0.18, as provided with Debian. Choose your poison!
In the case of PA I think, that just keeping our own copy of PA is way easier than both alternative solutions (that would need to be done for Fedora, SuSE, Mandrake, Slackware, OS-X, etc. again.)
Those of you running Linux might remember, that the popular Ardour harddisk recorder even kept a much bigger set of foreign libraries as private versions in its own CVS just to make compiling (and later packaging) *possible*. This included huge libraries like Gtkmm.
PA obviously is a much smaller piece of software to maintain in parallel than Gtkmm, so I think that as long as there is no proper release of PA 0.19 at this place: http://www.portaudio.com/download.html and as long as no proper packages for major OSses exist, including it in Pd is much easier - although of course it is not the clean solution in the long run: It's a compromise.
Ciao
On Sat, 17 Dec 2005, Frank Barknecht wrote:
So for doing Debian packages of Pd we could either elect someone to create portaudio packages that match our needs, or we'd need to make Pd run with PA 0.18, as provided with Debian. Choose your poison!
The poison I'll be choosing is to advocate reverting the change, and maybe even do it. If Tim wants to keep PA outside of devel_0_39 he should submit the idea to the democratic process that he advocates using.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Sat, 17 Dec 2005, Frank Barknecht wrote:
So for doing Debian packages of Pd we could either elect someone to create portaudio packages that match our needs, or we'd need to make Pd run with PA 0.18, as provided with Debian. Choose your poison!
The poison I'll be choosing is to advocate reverting the change, and maybe even do it. If Tim wants to keep PA outside of devel_0_39 he should submit the idea to the democratic process that he advocates using.
All I did was check in portmidi where Miller had overlooked it. Currently the way the "pd" section is set up is a mirror of Miller's development enviroment. It will only makes our lives more complicated if the CVS does not mirror Miller's development environment as much as possible (sadly ASIO can't be included, maybe we should replace ASIO with DirectSound support? DirectSound included in MinGW.)
As for devel, I have no intentions of doing anything with it, so I certainly wouldn't barge in and start making commits.
.hc
So for doing Debian packages of Pd we could either elect someone to create portaudio packages that match our needs, or we'd need to make Pd run with PA 0.18, as provided with Debian. Choose your poison!
pa18: portaudio api1 pa19: portaudio api2 please note, that it's portaudio 18, not 0.18!
All I did was check in portmidi where Miller had overlooked it. Currently the way the "pd" section is set up is a mirror of Miller's development enviroment. It will only makes our lives more complicated if the CVS does not mirror Miller's development environment as much as possible (sadly ASIO can't be included, maybe we should replace ASIO with DirectSound support? DirectSound included in MinGW.)
i guess, you've done extensive tests that verify that directsound gives as good latency results as asio?
So for doing Debian packages of Pd we could either elect someone to create portaudio packages that match our needs, or we'd need to make Pd run with PA 0.18, as provided with Debian. Choose your poison!
The poison I'll be choosing is to advocate reverting the change, and maybe even do it. If Tim wants to keep PA outside of devel_0_39 he should submit the idea to the democratic process that he advocates using.
feel free to check it in again ... that's probably the moment, when i'm going to fork off from devel_0_39 to have a codebase that i can use for my needs...
Am 18.12.2005 um 01:55 schrieb Tim Blechmann:
So for doing Debian packages of Pd we could either elect someone to create portaudio packages that match our needs, or we'd need to make Pd run with PA 0.18, as provided with Debian. Choose your poison!
The poison I'll be choosing is to advocate reverting the change, and maybe even do it. If Tim wants to keep PA outside of devel_0_39 he should submit the idea to the democratic process that he advocates using.
feel free to check it in again ... that's probably the moment, when i'm going to fork off from devel_0_39 to have a codebase that i can use for my needs...
Oh wow, what's that? - cool down your horses. To my mind the question if PA is inside or outside the cvs can't be a real reason to fork. If it's inside one can just simply ignore it - if it's outside, it's no problem either, since there's another site to grab it. For my part, in the previous mail, i was just talking about the devel branch, where i don't see real merits to have old PA sources sticking around. For Miller's branch, i see no problem keeping PA since it might help people compiling it, and others can still ignore it. What i definitely dislike is a power struggle about who's the keeper of the devel branch. (For me at least) There are currently other issues to worry about.
greetings, Thomas
On Sun, 18 Dec 2005, Tim Blechmann wrote:
The poison I'll be choosing is to advocate reverting the change, and maybe even do it. If Tim wants to keep PA outside of devel_0_39 he should submit the idea to the democratic process that he advocates using.
feel free to check it in again ... that's probably the moment, when i'm going to fork off from devel_0_39 to have a codebase that i can use for my needs...
Why do you now want to dismiss the democratic process that you were advocating?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
c -
Frank Barknecht -
Hans-Christoph Steiner -
Mathieu Bouchard -
Thomas Grill -
Tim Blechmann