On Mon, 15 Nov 2004, guenter geiger wrote:
On Mon, 15 Nov 2004, Matju wrote:
On Tue, 26 Oct 2004, guenter geiger wrote: One question... what's "pd extended" ?
right, but still, the CVS devel branch was not meant to be published. The fact that it was doesn't change the intention it was created for, or does it ?
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.
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...
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?
That was not my intention. I am trying to rephrase the section on patches in order not to sound arrogant.
It's also a matter of culture. For example, in Extreme Programming circles, it's consider normal to consider a missing feature to be a bug as soon as "make test" can figure out whether the feature is there or not, and that even if no line of implementation code has ever been written. But then it's not like Pd users can be expected to have any clue about that culture (especially given how the phrase Extreme Programming is used around here) so I'm not too sure it's relevant.
However the practice of using a bug-tracker with the partial intention of tracking feature-requests is apparently more widespread than just Extreme Programming... (?)
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)
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... ;-)
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.
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)
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju