[PD-dev] a few questions

[Hans-Christoph Steiner]

On Thursday, Apr 15, 2004, at 14:08 America/New_York, Tim Blechmann  
wrote:

> hi all,
>
>>> That said, I'm not going to put the burden of merging
>>> Miller's/devel's changes into impd, as it's already enough job to
>>> just get my changes working. I mean essentially I am rewriting
>>> pretty much all of the gui code and it's long enough that I can't
>>> afford to further slow myself down. Given the interest that impd
>>> generates, why wouldn't another developer actually handle that task?
>>
>> Well, we all hope more people step up and work on making Pd better,
>> but that doesn't happen as often as we'd like.
>
> i suppose there are a few developers out there, who might be interested
> in doing something to improve pd, but simply don't know, where to start
> / what to do / who to address ...
> that's a problem, because miller is working on his own, not on the cvs,
> some guys are working on the devel branch and mathieu working on the
> impd branch ...
> but shouldn't we be able to solve this by _actively_ using
> source-forge's feature request / bug tracking system? i mean, we could
> start with adding miller's todo list (is it up to date?) and try to  
> find
> a few people to work some of the tasks ... i don't think it's very
> useful if miller and mathieu are working on their branches on their own
> (?) and a few guys adding code to the devel branch every time a new
> stable release comes up ...

I wholeheartedly agree.  This sounds like an great idea.  There is a  
lack of organization, but that's not necessarily a problem.  Currently,  
the way things work is that people do things that they are motivated to  
do, and generally make sure they are not stepping on any toes.  It  
seems to have worked pretty well so far.  Its kind of like coordinated  
disorganization.

.hc

>
>>>>  And if Miller's changes aren't maintained in impd, then there
>>> would> be a fork.
>>>
>>> That's a pretty strange definition of fork. Maybe that's the
>>> slashdot definition of fork, I mean with the "bad, evil"
>>> connotations. To me, a branch and a fork are the same thing. Whether
>>> there is collaboration/osmosis between the branches is a separate
>>> issue.
>>
>> I think most people consider a fork like emacs vs. xemacs.  Any decent
>> sized development project has branches ( i.e. stable, release, devel,
>> etc.), but not necessarily forks.
> the problem of pd being a work in progress is, that it should be both
> usable and being developed at the same time ... it's not always
> necessary to branch between certainain versions, but sometimes it might
> be better to use compile flags / preprocessor macros to distingush
> between two different implementations ...
> mathieu, i don't know if this would work for what you are doing with
> impd, but for my taste it's better to have twice as much code and to be
> able to merge some of your changes to future "stable" releases ...
>
> just my 2.5 ¢ ... cheers...
>
>  Tim                          mailto:TimBlechmann at gmx.de
>                               ICQ: 96771783
> --
> The only people for me are the mad ones, the ones who are mad to live,
> mad to talk, mad to be saved, desirous of everything at the same time,
> the ones who never yawn or say a commonplace thing, but burn, burn,
> burn, like fabulous yellow roman candles exploding like spiders across
> the stars and in the middle you see the blue centerlight pop and
> everybody goes "Awww!"
>                                                           Jack Kerouac
>
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-dev
>

________________________________________________________________________ 
____

                     There is no way to peace, peace is the way.
										-A.J. Muste
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3896 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20040415/7f76ccd7/attachment.bin>