On Thu, 16 Aug 2007 11:49:39 +0200, mark carter <[EMAIL PROTECTED]>
wrote:
On Thu, 2007-08-16 at 16:37 +0800, Martin Ellison wrote:
Could you explain this more? svn allows branching, so why not just
create as many development branches as required and work there?
I do not know git, so could you please explain what git has over svn?
(Not intended as an attack).
SVN is centralised, git is decentralised. Git is reputably easier to
merge. It also has "scalability" advantages, esp. wrt branching. In git,
there is no authority. If I want to add a cool feature, I fork a
repository, and add a feature. My repo then becomes one among any number
of forks of the project.
It is successful for Linus on his kernel development, but I think in
Cinelerra it has lead to a bit of a mish-mash - surprising since the
Linux kernel is undoubtedly a 2,3,4 or even 5 orders of magnitude more
complex than Cinelerra.
I don't believe Cinelerra in its current state is 3 orders of magnitude
less complex than the Linux kernel. It _should_ have been, since the
problem domain Cinelerra covers is considerably smaller. I think a
rather radical rewrite is needed to bring Cinelerra's complexity on par
with the inherent complexity of the tasks an NLE like Cinelerra is
expected to handle.
Alas, it can not be made easy-peasy for budding hackers, unless great
sacrifices in functionality and/or performance are made. And we can't
have that, so Cinelerra will remain demanding on its coders.
I think the problem is that git is good at creating forks, but merging
is a social issue. So I might create a cool feature, but there's no
guarantee that it will make it upstream.
...
Now, I could go and take a copy of the Linux kernel, and immediately
produce a fork, declaring my branch to be superior. But that's a really
bad idea. It's a bad idea because no-one is interested in my fork. What
I probably should do if I want to submit a patch is branch something
that is interested in the kind of patch that I want to contribute, and
whose branch is eventually propagated upstream.
And I think this is the main problem we're seeing in Cinelerra: lots of
branches, but no upstream merging. So we're seeing lots of people making
useful contributions. but that the code is just whithering on the vine.
And I strongly suspect that as time goes on, the patches will become
unmergable. Probably git is much better at svn when it comes to merging;
but like svn, it isn't able to magically resolve code conflicts.
Certainly not. If you really want your additions to get widespread,
you want them to "go upstream". Paddling upstream can be a struggle;
often too hard if you don't get any help or support.
This is a fact of life that can hardly be eliminated. Submitting
a patch and saying "here you go" will only work if your patch is
both good and wanted, and upstream agrees. Upstream is expected to
either know and trust the patch submitters, or to review the patches.
Reviewing and testing takes some time and skill. By submitting a
patch you are either requesting other people to do some work for you,
or to trust that you tested the patch thoroughly.
You are absolutely right that merging is a social issue. Good code
does not merge itself with the upstream. You may have to talk to the
right people, and hope that you can persuade them.
Git makes it easy to create forks. But forking is a serious business,
and shouldn't be undertaken lightly.
I think interested parties really need to discuss this issue. And
perhaps we should be asking the question "should we even really have a
Cinelerra-CV version?"
Although Cinelerra is "good enough" for many users, it is also clear
that it attracts more rants and mockery than the community can live
with in the long run. Long term users keep wondering if they can
put up with Cinelerra, and wonder if _this_ year will bring a viable
contender.
Adam would not be able to fix this in a reasonable timeframe, even if
he was given an exhaustive TODO list. Neither will we, unless a lot
of the underlying code is redone to support all the stuff that an NLE
and compositor of the future should support. It has to be maintainable,
extensible and reasonably layered. It needs to be elegant and beautiful,
too, or too few coders will be attracted to it.
--
Herman Robak
_______________________________________________
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
