2007/11/12, mark carter <[EMAIL PROTECTED]>:
> > ... As you guys will no doubt be aware, I had created some
> > patches for Ficl, and left cinelerra alone for some time. When I tried
> > to apply the patches to a later version, there were quite a few
> > conflicts. Backed up from my other (limited) experiences with revision
> > control systems, I came to the conclusion that conflicts arise really
> > fast. Mergability is a real problem. I guess Linus must be some kind of God.
> 

Am Montag, den 12.11.2007, 17:25 +0100 schrieb Richard Spindler:
I think this depends on the project, most code in Linux are propably
> device drivers, that can be developed independently without
> interfering with others.
> 
Yes, it depends much on how the code is organized. 
In the current Cinelerra codebase, you get mergability problems very fast,
as soon as you try to "rework" anything, as opposed to just patch small 
changes into existing structure. So anything that is not so small, localized
or trivial as to be accepted into trunk very fast, is strongly discouraged.
In my oppinion /this/ is the root of the problem which looks from users view
as if "developers don't care for users needs".

Ideally, a sourcebase should be decomposed into several, not-so-strongly
coupled subsystems, and every coupling should be made explicit via 
interfaces. Then, for example, if you start your-favorate-new-feature
project as a new subsystem, maybe needing this and that addition to
other interfaces, and you get distracted and come back a half year
later, all you have to check in order to get up-and-running again,
is for modifications to the interfaces you used...

        cheers,
        Hermann Vosseler


PS: and you can take it for granted that we try to get into this 
direction with our cin3 work...

_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Reply via email to