mark carter wrote:
> Christian Thaeter wrote:
>> some personal opinions...
>>
>> A list of things which I would make me happy:
>>
>> * More people contributing to the project.
>>
>> * Help coding already planned and important things
>>
>> * Send patches (git mob?) which fix existing issues.
>>
> Looking at Cinelerra, I'm amazed at how Linus manages to get anything
> done with what must be a volley of patches that are flying all over the
> place.
>
> Git has the (big) advantage over svn in that if an ordinary Joe like me
> downloads a repo, I have immediate source control for my own work -
> whereas I'm given to understand that svn doesn't.
>
> I think the problem we're seeing is that there's good code going into
> mob that is not seeing its way upstream. And I don't think it ever will.
Well you likely can't imagine how much kernel patches and repositories
are all around and will never be merged :) .. same with git itself, when
you look at the Mailinglist you see a lot of proprosals which are
abadoned, thats the way free software works when it is under control of
a benevolent dictator.
For cinelerra things are little different:
If you mean HV by upstream, thats sadly true, we can't say anything
about what he might merge or not. For our own SVN, j6t merged mob
contibutions quite often in the past. I think sending things to the mob
and proprosing them on the mailinglist turned out quite well and even
got some drive recently. Of course mob won't get automatically
unreviewed merged into svn and no one wants to waste time, reviewing
something unfinished. So you can push things to mob, whenever you are
satisfied with the state, please post a merge proprosal to the ML.
Further we might decide to use only git in future and setup some shared
repository where some trusted people can push to for merges. This would
make the workflow considerably simpler.
> I'm not sure that the svn commiters pay much attention to what's going
> into mob. Perhaps we need someone who will clear patches. This can be
> difficult work. For example, I decided to take a look at the latest
> commit. It was by Craig Lawson. Now, what I am about to say is in no way
> meant to be a disrespect to Craig. If I were to review that commit,
> then, as a raw developer in cine, I'd be trying to ask myself what the
> problem is, and how his solution solved the problem. If I were doing my
> job meticulously, I'd look up what roundf() does, and try to convince
> myself that it does the right thing compared to int( ... + 0.5). I'd
> also note what appears to be some dubious code quality ... there's a
> block that seems repeated twice, but with slightly different values.
> Again, I want to emphasise that I'm not criticising Craig! There'd be
> quite a lot of work to do, even for a simple patch. From what little
> I've seen of the Cinelerra code, it's a big victim of cut-and-paste
> programming. I'm sure it did what it was supposed to do for the original
> author at the time, but to an outsider, it's very very messy.
Hey we use a distributed revision control system, this means we can
merge code which is only coarsely reviewed to not contain backdoors and
obliviously bad code into a 'very_experimental' branch which might be a
starting point for all kinds of code to evolve until they eventually hit
the mainline. I don't think code has to be reviewed and validated to
every single aspect from the very start on. We can do some
experimenting, git is *very* good in 'software archelogy' which lets you
exactly track the history of each single function and line. Things are
easy reverted and thrown away when they turn out be be bad. Code has to
be written few times until it is satisfactionable in my experience anyways.
On the other side, I have strong suspects that the code Craig pushed
there is useful for him and quite likely for many others too. So I would
vote for generous inclusion of mob code into a experimental branch,
setting the barrier quite low.
The question here is, "Who decides" and I have the feeling that we
should just decide by doing it. So whenever one wants to go ahead and
pick this up, just do it.
>
> I think it would be very useful to have someone act as a clearing house
> for bug fixes. It's /possible/ (no promises!) that I might have some
> free time in the new year, and could contribute in this way.
>
>
>> * Caring for infrastructure,
>
> Well, one thing that disappointed me recently is that I submitted a
> patch that added some doc-building infrastructure. I created a
> Makefile.am, which I think is a start to getting docs built
> automagically. I incorporated the facility for generating info files, so
> that you could type
> info cinelerra
> and get info about cinelerra. Now, admittedly, what I had submitted was
> crude - from the "release early, release often" school - but it doesn't
> look like my patch is ever going to make it into svn. That being the
> case, I'm disinclined to polish my efforts further.
Hey, i've rewritten the whole build system, cinelerra build in 3 minutes
here now. It was just a start and has some rough edges but it works for
me. But noone cares so it won't come into mainstream anytime soon.
>
>> Things which don't turn me on and are a time sink:
>>
>>
>> * Adding more requests to the pile of things which have to be done.
>>
> Good point. I made a mistake when I added Ficl. Thankfully it never made
> its way into the codebase!! - although you can still try it out from my
> git repo (the ficl branch on my machine compiles fine). More than
> anything, I think that Cinelerra needs stability over feature requests.
>> * Endless talks without productive outcome.
>>
> We need a Benevolent Dictator For Life! Well, maybe.
Not really sure if we need such a person .. maybe, but currently there
is no one who qualifies for that job. I think we shall adjust our
workflow to this fact. Thats what I aim for cin3, anyone can contribute,
using git from start on, everyone makes decisions only for himself.
Others the have the freedom to merge and improve on whats flying around,
letting only good ideas evolve and propagate and finally find their way
into releases.
Christian
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
