mark carter wrote:
> 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.
Merge often, try fake merges which you undo when there are no conflicts,
or rebase your work on top of the svn-git. This ensures far less pain
than a long delayed merge with many conflicts.
>> 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?
There are no restrictions on how to use the mob. Give it a try, but keep
in mind that this branches have to be kept in sync, I may argue that
long-living bugfix branches won't scale. But really its open for any
try, we will see what works best.
I would suggest to use a rather hieracic way where anyone first has his
own branch, then maybe his own sub-branches for features or bugfixes and
these are then merged against a 'bugfix-incoming' branch which is
otherwise in sync with the mainline. Depending on the traffic on this
bugfix-incoming it might temporary split up in more branches, some bugs
certainly need more attention and longer testing and work, while others
are done with a few lines.
>> 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.
Thats was my personal opinion, I am already quite sure some people
disagree with it :). But well, don't misunderstand me that I would
accept bad quality, my point is just that there has to be some start
even an unacceptable contribution might lay a seed for a better fix and
evolve into something good.
Christian
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
