[PD-dev] re: branch convergence

[Matju]

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