[PD-dev] re: branch convergence

[guenter geiger]

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.

> > 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