Christian Thaeter wrote:
mark carter wrote:
For cinelerra things are little different:
If you mean HV by upstream,
Primarily I meant CV - I was assuming (very dodgy assumption, I know)
that HV and CV perform a cross-merge, on the basis that it's all good stuff.
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.
What I think would be nice for git would be a facility where one could
describe a branch, and add status messages without necessarily commiting
files. Maybe a bogus "diary"/ChangeLog might do the trick, or something.
So you can push things to mob, whenever you are
satisfied with the state, please post a merge proprosal to the ML.
Thanks. Although I can't do it now - maybe at the end of this year -
I'll have to see how my repo can be connected to mob and my branch on
your machine. No doubt things have gotten hideously mangled and will
need some surgery on my part.
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 thinking out loud here. What about the idea that we use mob in a
slightly different way. If someone wants to fix a bug (bug 123, for
example), they create a new branch bug123 off mob, and push their
changes to that branch. When complete, they mail the list, it gets
reviewed for backdoors, and a test compilation is done against svn
backported changes +all the bugs integrated so far. I'm not sure what
we'd do about experimental or other stuff - we'd need to chew that one
over.
What this means is that we have specific heads that identify specific
bugs, we have some quality control with a low barrier, and we get code
that compiles cleanly (or else the branch is rejected). So, in this way,
we're really trying to maximise our chances of getting those bugfixes
upstream. Sound useful?
Hey we use a distributed revision control system, this means we can
merge code which is only coarsely reviewed to not contain backdoors
OK. I wasn't sure how much quality control was applied.
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
