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 <avi...@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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________ Kdenlive-devel mailing list Kdenlive-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
