On Nov 16, 2004, at 5:55 AM, guenter geiger wrote:
On Mon, 15 Nov 2004, Matju wrote:
Well, depends who was involved in the process of publishing "pd extended". It may tell something about the seriousness of the original intent. And then there are intents that are platonician as in "well, if the world were as perfect as i'd like it to be, then X" and there are others that are positivist as in "given the current state of the world, then X". So I'd like to know what is the reasoning that led to that intent.
I think it is more platonician then. I am trying to avoid a branch. This might be a very conservative approach and I would probably (surely?) act differently there would be a feature that I want to have in Pd. A good example is the alsa sequencer support, which is built in in the experimental debian package. I did not do a split of Pd though, it is just a patched version.
Let me rephrase the whole question. If someone would ask me if I created the CVS for developers in order to publish an improved version of Pd, I would say "no". I created it in order to help the development on the Pd core and to make it possible to work together on new ideas, ideas that are then eventually incorporated into the official version.
I also think that its very important that we avoid splitting the Pd devs, but I don't think that distributing binaries of devel would necessarily be a bad thing, or lead to a fork. The real key here is communication. And I think we agree that the goal of our work is to have one unified Pd. I think that we should be distributing binaries of major branches like devel and impd so that the ideas and code in those branches can get thoroughly tested by a broad range of people. Then it should become apparent what works and what does.
I think we can see examples of this being done in a friendly manner, and I think it will make a fork less likely because there will be an outlet for trying new things. An example I recently came upon is the gaim-vv fork. They are developing voice and video support in a friendly fork, and once its done, they will fold everything into libgaim.
.hc
Actually patches that will not get accepted should be rejected and closed. This way I hope that there won't be too many patches lying around.
Ok, so any submitted patches should be sufficiently short-term to remain conflict-free, and any conflicting patch has to be resubmitted in a better form. Already sounds better.
Yes, you are right. What if I change bug-report.php to trackers.php ?
I don't know, "trackers" is also an overloaded word in computer-music circles :-( but then, one name has to be picked at one point and it won't necessarily be ideal...
Already called it like that without thinking :(
I can also call the menu entry "Trackers", or just write "feature requests" instead of FR, but it makes the menu entry quit lengthy. The reason for concentrating on the bug reporting aspect was that I thought that is what most of the users would do.
Maybe something like "Change Request" sounds like it'd encompass both "Bug Report" and "Feature Request" while sounding neutral/generic enough. What do you think?
Well, but it lacks the clearness of "Patches". The Patches tracker is meant to put source code. "Change Request" is too similar to feature request I think.
I just sort of mixed up the two purposes of patches, which is bug fixes and new features. Thanks for pointing it out.
Well, there's a simple, nice reason for that: it's that those two purposes are very alike in the way that those development processes happen to be formalized (which is why i mentioned "change request" as a common name)
Well, I am not fully conviced that a name change of the tracker would currently be a good idea. Lets just look how many pd patches (in the sense of abstractions) get uploaded. The name conincidence is really unfortunate ...
You are right, I wrote that as a buzz word, so that people accept the system.
I didn't know you have leanings towards marketing... ;-)
I had to learn to do this, otherwise people won't listen.
The question now is, who is responsible for creating the patch. I think that it is not a lot harder to create the patch than to merge back the changes in CVS.
Well, the way I thought about it in the last mail, is that a change merged back to CVS only has to be compatible with the head of the branch, whereas a free-floating patch is usually expected to work at least with a large enough range of revisions of a given branch. Now if you say that the patches are short-term then the difference between the two is less important, but I wonder how many short-term patches will slip into the long-term domain.
Has to be seen. I am not against changing the system if there is a need for it. Currently we are in the test phase.
Of course your case is a special one, because you have changes that are going deeper into the core of Pd than others. I don't know really how to solve this, it is likely that the system we have is not up to this task. What would be your proposal ? Lets talk about it.
My proposal could be to honestly try the system for a while and see how much trouble I get in practice... (not all troubles can be realistically avoided upfront and I feel I'm attempting to forecast a bit too much already)
Ok. It is a good thing to expect the worst things to happen, this way it is possible to deal with possible problems in advance. We just have to remember that the system is here for helping us to collaborate. If it fails in that, we have to change it.
Guenter
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams