From: [EMAIL PROTECTED]
Reply-To: [email protected]
To: [email protected]
Subject: Cinelerra digest, Vol 1 #1852 - 9 msgs
Date: Thu, 16 Aug 2007 15:16:26 +0200
Send Cinelerra mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Cinelerra digest..."
Today's Topics:
1. Re: WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2
maintenace (Martin Ellison)
2. Re: WHERE CINELERRA IS GOING? ...anyone? proposal for
CinelerraCV 2 maintenace (mark carter)
3. Re: WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV
2 maintenace (Christian Thaeter)
4. Re: WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2
maintenace (Martin Ellison)
5. Re: WHERE CINELERRA IS GOING? ...anyone? proposal for
CinelerraCV 2 maintenace (mark carter)
6. Re: WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2
maintenace (Herman Robak)
--__--__--
Message: 1
Date: Thu, 16 Aug 2007 16:37:57 +0800
From: "Martin Ellison" <[EMAIL PROTECTED]>
To: [email protected]
Subject: Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for
CinelerraCV 2 maintenace
Reply-To: [email protected]
------=_Part_170829_31001055.1187253477941
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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).
On 16/08/07, Christian Thaeter <[EMAIL PROTECTED]> wrote:
>
> ...
>
> 2) Stop using SVN
> Even if commit access is generously handled to people who ask, it's
> still a big blocker as I explained earlier. As long we have only one
> linear history everything has global impact and there is no easy way to
> add new features without running in troubles. There is no easy way that
> small groups of people try and review new features, no easy way to get
> good but intrusive new ideas back into CV.
>
> --
Regards,
Martin
([EMAIL PROTECTED])
IT: http://methodsupport.com Personal: http://thereisnoend.org
------=_Part_170829_31001055.1187253477941
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<br>Could you explain this more? svn allows branching, so why not just
create as many development branches as required and work there? <br><br>I
do not know git, so could you please explain what git has over svn? (Not
intended as an attack).
<br><br><div><span class="gmail_quote">On 16/08/07, <b
class="gmail_sendername">Christian Thaeter</b> <<a
href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</a>> wrote:</span><blockquote
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204);
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
...<br><br>2) Stop using SVN<br>Even if commit access is generously handled
to people who ask, it's<br>still a big blocker as I explained earlier. As
long we have only one<br>linear history everything has global impact and
there is no easy way to
<br>add new features without running in troubles. There is no easy way
that<br>small groups of people try and review new features, no easy way to
get<br>good but intrusive new ideas back into
CV.<br><br></blockquote></div>
-- <br>Regards,<br>Martin<br>(<a
href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</a>)<br>IT: <a
href="http://methodsupport.com";>http://methodsupport.com</a> Personal: <a
href="http://thereisnoend.org";>http://thereisnoend.org</a>
------=_Part_170829_31001055.1187253477941--
--__--__--
Message: 2
Subject: Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for
CinelerraCV 2 maintenace
From: mark carter <[EMAIL PROTECTED]>
To: [email protected]
Date: Thu, 16 Aug 2007 10:49:39 +0100
Reply-To: [email protected]
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 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. What Linus does is have a core
of developers who he trusts, and he willingly accepts patches from his
core team. He probably doesn't even look at what anyone else does. Now,
those core developers probably work in key separate areas, meaning
clashes are kept to a minimum. The core team, in turn, have their
trusted sources - and in this way, the whole thing builds like a pyramid
with Linus at the apex, Lord of all he surveys.
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.
I think what I'm saying is that git is merely a tool, it doesn't solve
the social and organisational issues. That's for humans to sort out.
At the moment, what I see, as I understand it, is:
* Cinelerra-HV, which is Heroine's version
* Cinelerra-CV, which is basically HV plus or minus a few patches,
* "ct", which is happy to part from both, attempting to bring
architectural improvements and some bug fixes
* cinelerra 3, which is basically a Cinelerra redesign
* a number of other players (including my branch), which attempt to do
various things in various combinations
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?"
Another key question might be: "who produces the most code: HV, or CV"?
If HV is chugging along at a steady pace, rarely accepting patches,
whilst CV is mired in difficulties, then one might form the conclusions
that it's better just to use HVs code, and forget about CV, or maybe
just use it for occasional minor bug fixes. OTOH, if the opinion is that
HV is sluggish, buggy, and the CV version would be more dynamic, then we
should probably conclude that we should form a proper fork, probably
using git, and let HV play catch-up with us. It all depends what you
think.
--__--__--
Message: 3
Date: Thu, 16 Aug 2007 11:50:50 +0200
From: Christian Thaeter <[EMAIL PROTECTED]>
To: [email protected]
Subject: Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for
CinelerraCV
2 maintenace
Reply-To: [email protected]
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).
I am out of office today.
In short: SVN allows branching but does not support (enough) merging
and has many many more problems.
Best let linus explain:
http://uk.youtube.com/watch?v=4XpnKHJAok8
Christian
--__--__--
Message: 4
Date: Thu, 16 Aug 2007 18:50:55 +0800
From: "Martin Ellison" <[EMAIL PROTECTED]>
To: [email protected]
Subject: Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for
CinelerraCV 2 maintenace
Reply-To: [email protected]
------=_Part_171493_9872521.1187261455164
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
ok, I've found http://git.or.cz/course/svn.html.
On 16/08/07, 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 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. What Linus does is have a core
> of developers who he trusts, and he willingly accepts patches from his
> core team. He probably doesn't even look at what anyone else does. Now,
> those core developers probably work in key separate areas, meaning
> clashes are kept to a minimum. The core team, in turn, have their
> trusted sources - and in this way, the whole thing builds like a pyramid
> with Linus at the apex, Lord of all he surveys.
>
> 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.
>
> I think what I'm saying is that git is merely a tool, it doesn't solve
> the social and organisational issues. That's for humans to sort out.
>
> At the moment, what I see, as I understand it, is:
> * Cinelerra-HV, which is Heroine's version
> * Cinelerra-CV, which is basically HV plus or minus a few patches,
> * "ct", which is happy to part from both, attempting to bring
> architectural improvements and some bug fixes
> * cinelerra 3, which is basically a Cinelerra redesign
> * a number of other players (including my branch), which attempt to do
> various things in various combinations
>
> 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?"
>
> Another key question might be: "who produces the most code: HV, or CV"?
> If HV is chugging along at a steady pace, rarely accepting patches,
> whilst CV is mired in difficulties, then one might form the conclusions
> that it's better just to use HVs code, and forget about CV, or maybe
> just use it for occasional minor bug fixes. OTOH, if the opinion is that
> HV is sluggish, buggy, and the CV version would be more dynamic, then we
> should probably conclude that we should form a proper fork, probably
> using git, and let HV play catch-up with us. It all depends what you
> think.
>
>
> _______________________________________________
> Cinelerra mailing list
> [email protected]
> https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
>
--
Regards,
Martin
([EMAIL PROTECTED])
IT: http://methodsupport.com Personal: http://thereisnoend.org
------=_Part_171493_9872521.1187261455164
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
ok, I've found <a
href="http://git.or.cz/course/svn.html";>http://git.or.cz/course/svn.html</a>.<br><br><div><span
class="gmail_quote">On 16/08/07, <b class="gmail_sendername">mark
carter</b> <<a href="mailto:[EMAIL PROTECTED]">
[EMAIL PROTECTED]</a>> wrote:</span><blockquote
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204);
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Thu, 2007-08-16 at 16:37
+0800, Martin Ellison wrote:
<br>><br>> Could you explain this more? svn allows branching, so why
not just<br>> create as many development branches as required and work
there?<br>><br>> I do not know git, so could you please explain what
git has over svn?
<br>> (Not intended as an attack).<br><br>SVN is centralised, git is
decentralised. Git is reputably easier to<br>merge. It also has
"scalability" advantages, esp. wrt branching. In git,<br>there is
no authority. If I want to add a cool feature, I fork a
<br>repository, and add a feature. My repo then becomes one among any
number<br>of forks of the project.<br><br>It is successful for Linus on his
kernel development, but I think in<br>Cinelerra it has lead to a bit of a
mish-mash - surprising since the
<br>Linux kernel is undoubtedly a 2,3,4 or even 5 orders of magnitude
more<br>complex than Cinelerra.<br><br>I think the problem is that git is
good at creating forks, but merging<br>is a social issue. So I might create
a cool feature, but there's no
<br>guarantee that it will make it upstream. What Linus does is have a
core<br>of developers who he trusts, and he willingly accepts patches from
his<br>core team. He probably doesn't even look at what anyone else does.
Now,
<br>those core developers probably work in key separate areas,
meaning<br>clashes are kept to a minimum. The core team, in turn, have
their<br>trusted sources - and in this way, the whole thing builds like a
pyramid<br>with Linus at the apex, Lord of all he surveys.
<br><br>Now, I could go and take a copy of the Linux kernel, and
immediately<br>produce a fork, declaring my branch to be superior. But
that's a really<br>bad idea. It's a bad idea because no-one is interested
in my fork. What
<br>I probably should do if I want to submit a patch is branch
something<br>that is interested in the kind of patch that I want to
contribute, and<br>whose branch is eventually propagated
upstream.<br><br>And I think this is the main problem we're seeing in
Cinelerra: lots of
<br>branches, but no upstream merging. So we're seeing lots of people
making<br>useful contributions. but that the code is just whithering on the
vine.<br>And I strongly suspect that as time goes on, the patches will
become
<br>unmergable. Probably git is much better at svn when it comes to
merging;<br>but like svn, it isn't able to magically resolve code
conflicts.<br><br>I think what I'm saying is that git is merely a tool, it
doesn't solve
<br>the social and organisational issues. That's for humans to sort
out.<br><br>At the moment, what I see, as I understand it, is:<br>*
Cinelerra-HV, which is Heroine's version<br>* Cinelerra-CV, which is
basically HV plus or minus a few patches,
<br>* "ct", which is happy to part from both, attempting to
bring<br>architectural improvements and some bug fixes<br>* cinelerra 3,
which is basically a Cinelerra redesign<br>* a number of other players
(including my branch), which attempt to do
<br>various things in various combinations<br><br>Git makes it easy to
create forks. But forking is a serious business,<br>and shouldn't be
undertaken lightly.<br><br>I think interested parties really need to
discuss this issue. And
<br>perhaps we should be asking the question "should we even really
have a<br>Cinelerra-CV version?"<br><br>Another key question might be:
"who produces the most code: HV, or CV"?<br>If HV is chugging
along at a steady pace, rarely accepting patches,
<br>whilst CV is mired in difficulties, then one might form the
conclusions<br>that it's better just to use HVs code, and forget about CV,
or maybe<br>just use it for occasional minor bug fixes. OTOH, if the
opinion is that
<br>HV is sluggish, buggy, and the CV version would be more dynamic, then
we<br>should probably conclude that we should form a proper fork,
probably<br>using git, and let HV play catch-up with us. It all depends
what you<br>
think.<br><br><br>_______________________________________________<br>Cinelerra
mailing list<br><a
href="mailto:[email protected]";>[email protected]</a><br><a
href="https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra";>
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra</a><br></blockquote></div><br><br
clear="all"><br>-- <br>Regards,<br>Martin<br>(<a
href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</a>)<br>IT: <a
href="http://methodsupport.com";>
http://methodsupport.com</a> Personal: <a
href="http://thereisnoend.org";>http://thereisnoend.org</a>
------=_Part_171493_9872521.1187261455164--
--__--__--
Message: 5
Subject: Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for
CinelerraCV 2 maintenace
From: mark carter <[EMAIL PROTECTED]>
To: [email protected]
Date: Thu, 16 Aug 2007 13:31:31 +0100
Reply-To: [email protected]
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?
git allows a project to be forked easily, whereas svn is geared towards
central command. svn requires centralised commit privileges, whereas git
does not.
When I clone a project using git, I am forking someone else's project.
Someone else can do the same to mine. Now, I can continue developing my
fork independently of everyone else; but hopefully more likely, I am
aiming to get my code propagated all the way to the top. How I do this
(well, it doesn't HAVE to be done this way, I am merely illustrating) is
that I approach the guy that I forked from to incorporate my patches. If
he does so, then hopefully someone further up the chain trusts the guy
that I submitted my patches to, so he incorporates them too. So the
patches filter up the chain.
Compare this to svn, where you need permission granted right at the top
of the chain from the outset, and with no "chain of command" in
intermediate layers.
The git model works for Linus, but doesn't appear to be going too well
for Cinelerra. What I believe we're seeing is not much in the way of
upstream integration. So when people fork, they're in effect creating a
true fork, leading to a "balkanisation" (although that might be too
strong a word) of the code.
--__--__--
Message: 6
Date: Thu, 16 Aug 2007 15:14:02 +0200
To: [email protected]
Subject: Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for
CinelerraCV 2 maintenace
From: "Herman Robak" <[EMAIL PROTECTED]>
Reply-To: [email protected]
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
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
End of Cinelerra Digest
