[Kdenlive-devel] Git workflow

[jb]

On Friday 04 November 2011 15:11:40 you wrote:
> On Friday 04 November 2011 15:05:18 Alberto Villa wrote:
> > Last case I can think of: *.1 revision. You tag 0.x.y from master, and
> > then merge feature A to it. But people starts screaming that 0.x.y
> > removes root partition. So you checkout tag 0.x.y (all these tasks are
> > *instant*
> in
> 
> > Git), branch off from it, delete the "rm -rf /*` hidden in Kdenlive
> > configuration wizard, and tag 0.x.y.1 from the branch. To complete the
> > operation, you merge the branch into master (and solve potential
> > conflicts, should the `rm -rf /*` have been changed to `sudo rm -rf /*`
> 
> in
> 
> > master).
> 
> Oh, and you then merge master to next. ;)

Hi Alberto and all!

Thanks for the explanations! I now have read your mail 3 times and I think I 
understood! So if I put it in other words, it would work like this:

* If I want to fix a simple thing:

- I work on it on my local copy of master and commit it directly to master, 
then it is also merged to 'next'.

* If I want to work on something more complicated, ex. rewrite effect stack:

- I create a remote 'feature' branch from master
- I work on it and commit my changes to the branch, other people can also help
- When it is ready for testing, I merge my branch into 'next'
- Bug fixes go in my 'feature' branch and are merged again in 'next' for 
testing
- When it is stable, my 'feature' branch is merged into 'master', 'master' is 
merged into 'next' and my remote 'feature' branch is deleted.

* Of course one can also work on a local branch of master for some reasons...

Now, I have 2 questions / comments:

1) What about string freeze? My proposal to wait a few weeks before merging 
new features after a release was to make sure that no new string is introduced 
if we make a .1 release. But then it would block development, so I think that 
if we need to make a .1 release, it is probably better to do as you proposed: 
create a new branch from the release tag, fix the problems in this branch, 
create new release from that branch then merge changes to master.

2) Are some of the merges automated? I mean that if I fix a stupid bug in 
'master', will it automatically be merged to 'next' or do I have to do it 
manually? 

We shoud probably set up a web page to list the commands for the most common 
operations (create a branch, merge it to next, how to update your branch with 
latest changes from master or next, ...)


Regards
jb