[PD-dev] re: branch convergence

[guenter geiger]

On Fri, 22 Oct 2004, cr wrote:
> hi, my last mail got nuked by the server, did you change config? it
> never used to have a prob with a faked 'from' field to match the
> subscribed address...
>
>
> anyways my vote is do away with the numbers. ive made a lot of minor tweaks
> to devel, which ive already made to impd as well, and definitely don't
> want to make them a 3rd time (that would be 3 strikes..). to fix/add
> stuff like:

> / .pdrc not being read on windows (pd.ini)
> / not being able to select 2 outs and 6 ins with portaudio
> / not being able to put tcl in your system path on win32
> / no ASIO with non-MSVC on win32.
> / a few linux64 fixes
> / merge jsarlo's VST io sppt
> / almost everything from impd that wasnt in g_* files
>
> nonetheless in the actual code theyre too trivial for anyone else to notice, and an order of magnitude smaller than the contributions Tim has made, but i wouldnt want them to get lost..so in order of preference from most to least
>
> 1: do away with numbering, and just have a 'devel'. every month or so, make
> sure it compiles on all 3 platforms and dump into MAIN..theres few enough
> developers and i dont think theyre stepping on toes and generally work
> on difft things..
> 2: keep numbering, but devel_0_56 becomes devel_0_57, so the 'little guy's
> stuff isnt lost, and so he doesnt have to bug miller or guenter or
> whoever and possibly paste a bunch of stuff in again and get grey
> hairs..
> 3: crazy all-night frankenstein hack/merge fest with version # change that
> might lose features and add new bugs..

One thing that is pretty clear is that it won't be done through a
unconditional merge of devel into main. That is something that Miller
doesn't want, and I fully understand that.

Your proposal 2 is how it is done currently.

Your proposal 3 is probably how it is done in the future, because
the person who has done the merges up to now has stepped back
from these boring duties.

There is one additional "feature" which comes into play, and that is
the patches tracker. If you want your changes to be included in the
main version you have to submit a patch against the latest MAIN branch.

This is a test to ease the inclusion of new features und bug
fixes in the main branch. Don't know if this succeeds, because
it depends if it will be accepted by the developers *and* by Miller.
Sorting out the "good" changes from the  "bad" changes in the devel
branch is a lot of work. Having the different changes split up
in manageable patches will make this a lot easier. Bug  fixes
can be applied almost immediatly, without having to sort out
what belongs to the bug fix and what not. The single patches can
easily be reviewed by other developers. They can be applied in
isolation and be tested without the influence of other changes.

Guenter

>
>
> i mean the same reason i'd vote for 'devel' as rather using debian 'sid' than 'sarge' or something thats doomed (like win32)...
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-dev
>