[Kdenlive-devel] Git workflow

Fri Nov 4 14:05:18 UTC 2011

On Friday 04 November 2011 09:23:09 Simon A. Eugster wrote:
> Hey Alberto, hey jb!
> 
> On 11/03/2011 04:36 PM, jb wrote:
> > I have no experience with git, so I am not the best person to 
comment.
> > However it seems a good idea to have "master" that would always be 
in a
> > "releasable" state (when translations are ready), and "next" that 
would
> > be more like our current svn trunk.

Be aware that the idea is not to do development on next. next should 
only be a target for merges from feature branches (for complex things) 
and master (for easy bux fixing). In theory, development only goes on 
master and feature branches. If you develop directly on next skipping 
feature branches, you cannot merge only stable code to master 
because next will contain both stable and unstable one.

> > I am not sure about the "release" branches. We don't really have the
> > energy to maintain several "stable" branches

Of course we don't, and that wasn't my idea, it was just for urgent fixes. 
Anyway I agree, I don't like the idea.

> > so my idea would be that
> > when we make a new Kdenlive release (from the "master" branch), we 
wait
> > like 2 weeks before merging changes from the "next" branch.

A side note: you don't merge from next to master, but from feature 
branches to master. next is just a "catch all" branch, it may contain both 
stable and unstable features/fixes.

> > That way, if
> > some serious issue appears in these 2 weeks after a release, we can
> > easily make a new minor release fixing just a few bugs from the 
previous
> > release.

I like this idea. Nonetheless, I got one which might be better (and gives 
less constraints). Let's tag releases and go on with development as 
usual. Let's merge a feature to master - when stable - even two days 
after the release. Then, if we find a serious bug which calls for a *.1 
revision, we just branch off the tag and create a branch for *that* 
revision. We apply the fix to the branch (and merge it back to master), 
and tag the new *.1 revision.

> I agree; I'm not too experienced with git either, but I would try to
> keep the number of branches minimal as well. Is there something that
> speaks against using tags for releases and using a release branch 
instead?

The point was about urgent bug fixes which require an immediate 
release (again, think of 0.7.7.1). My whole point is explained above. I 
agree about keeping the number of branches low.

> Regarding the feature branches, if I understand correctly these are
> public private branches, i.e. for example when I decide to break the
> titler again and want to have my work backed up in git. So the rest of
> you can still go on developing in the «next» branch without all the
> segfaults I introduced in my feature branch (Until I merge them with 
the
> «next» branch). Right?

Yes and no. First thing first, as explained above: development only goes 
on master and feature branches, not next. Then, branches can be 
remote or local, it depends on you. Will its feature/fix take some time 
(remote++) or is it a short life branch (local++)? Do you want other 
people to be able to work on/review it (remote++)? Or is it your private 
baby and no one can see it until it's ready (local++)?

Look at this image: http://community.kde.org/File:Kde-git-workflow.svg

Now forget the "Release" branch (again, apart for post-release fixes, 
where we'd branch from the release tag). "Integration" is "next".

The idea is that everything gets branched from master, and only master. 
Development goes on master (for easy stuff which cannot affect 
stability in negative terms), and on feature branches. A feature branch 
can also be created for a not-so-trivial (yet not complex) bug fix which 
requires some commits (remember that in Git you're encouraged to 
commit often, with small patches). When you feel like letting people 
test your uncomplete feature/fix, you merge your branch to next, and 
go on with development in the branch. When the feature/fix is stable 
(maybe not complete, but in a releasable state), you merge *the 
branch* to master.
To do a parallel to our SVN "refactor" branch, in Git we wouldn't have 
one big refactor branch, but, e.g., a "buildsystem" one (my field :P), a 
"trackclass" or whatever for Till's work on a track class, and so on... 
Smaller, better targeted branches.

Also, to make "next" usable, you'll need to merge the small fixes you 
happen to do directly in master to it. Plus, if your fix affects code 
touched in a branch, you (or the guy working on that branch) have to 
merge that fix to that branch as well, so to avoid possible conflicts in 
the future.

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).

Have I been complicated enough? Actually, it's much simpler than it 
sounds (I've started using this workflow on a project of mine to see how 
it works, and found it quite easy).

Now that my ideas should be more deeply explained (if they aren't, 
sorry, just ask), comments?
Excuse me if I may have talked like this *will* be our workflow. I'm not 
trying to prevaricate, it was just for ease of speech. ;)
-- 
Alberto Villa, FreeBSD committer <avilla at FreeBSD.org>
http://people.FreeBSD.org/~avilla

I have no doubt that it is a part of the destiny of the human race,
in its gradual improvement, to leave off eating animals.
		-- Thoreau
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 314 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20111104/f2a62488/attachment.sig>