Burkhard Plaum wrote:
> Hi,
>
> Christian Thaeter schrieb:
>> Richard Spindler wrote:
>>> 2007/11/12, Christian Thaeter <[EMAIL PROTECTED]>:
>
> [...]
>>> - Minor contributers send patches to Mailinglist. If patches are okay
>>> and plenty, minor contributor is given commit access and becomes major
>>> contributor.
>>
>> Imo too much work, someone has to pick the things up from the
>> mailinglist and commit them somewhere,
>
> Depends on how many patches you expect to get per day.
>
> People talk a lot about git and other tools, and I believe that for
> high-traffic projects there *is* a difference. But for "low-traffic"
> projects (which cinelerra is with respect to patches), the mailing-list
> model works perfectly as long as someone feels responsible for patches
> (and understands the code enough to review them).
Cinelerra currently lacks this responsibility, so far I think no one
would like to do this job. Further plain patches loose valuable
information (Who was the original author, what where the intentions,
when was the patch created, based on which source, ...) This are the
things a revision control system provides.
Git knows a email based workflow, in fact git itself is developed this
way, which is rather high volume. Traffic makes no difference. I feel
much more convinient with using git in a push/pull model, others might
prefer the ML, that is ok as long we have some way to commit patches
without loosing associated metadata which is somewhat important.
>
>>> - Independent code chunks are spinned of into seperate projects. API
>>> is fixed. If an API change is neccessary, he how proposed the change
>>> needs to provide patches to affected projects.
>
> Well, there are quicktime4linux and libmpeg3. Don't know how independent
> they
> are nowadays.
>
> What's IMO much more important to attract contributors is the code
> itself: When I look
> at the sourcecode of ffmpeg, it's quite easy to find where and how
> things are done.
> If I want e.g. to understand how cinelerras filters work, I see a poorly
> documented
> mixture of GUI-routines and functional routines. Maybe it's my allergy
> against C++,
> but I doubt, that many people will jump in and start writing/improving
> cinelerra
> filters...
>
> I can tell a bit about that, because 5 years ago we did the same thing
> as you: Fork
> code from heroinewarrior.com, libquicktime in our case.
> In the beginning it was actually just a patch, and we tried to be
> compatible to qt4l.
> But then the decision was: Either keep the code like it is (keeping
> compatibility),
> or clean it up, so others can work on it as well (but loosing
> compatibility).
> I (being the only member from the original team) decided for the latter,
> and still
> think it was right. This is no offence against any upstream developers:
> Many of my
> daily programming techniques are learned from qt4l.
>
> Burkhard
This will be done better in cin3, using extern libs if possible, try to
avoid to patch common libs, document code, write testsuites,...
Christian
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
