[PD-dev] re: branch convergence

[Hans-Christoph Steiner]

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