[Kdenlive-devel] Git workflow
avilla at freebsd.org
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
> > However it seems a good idea to have "master" that would always be
> > "releasable" state (when translations are ready), and "next" that
> > 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
> > 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
> > 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
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
> «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
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
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>
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 314 bytes
Desc: This is a digitally signed message part.
More information about the Kdenlive