Git Worflow, branch creation.

Maksim Orlovich mo85 at cornell.edu
Tue May 17 16:42:41 BST 2011


Testing.

If everyone is working on branches on cool new stuff, the release will be crap.


On 5/17/11, Alexis Ménard <menard at kde.org> wrote:
> Hello,
>
> Not sure this was discussed before but I'd like to bring the topic for
> discussion.
>
> Now that KDE moved to git it seems we still have old habits like
> "Freezing period" on trunk (or should I say master branches of each
> git repos). That sounds like weird to me when one of the main feature
> of git is branch management. Unlike SVN it's easy for anyone to switch
> from a branch to another one, making back-porting patches very easy,
> checkouting being 10 times more easy.
>
> I know it's a wider announcement so that people focus on bug fix
> rather than feature (which is great). Now I don't understand why the
> branching of let say 4.7 does not happen before on each repo (when the
> freeze is decided) and we could make the policy on branches way more
> clear and defined what could go on the branch and what can't go (just
> using the procedure we have today). It has always been annoying the
> fact that you couldn't hack features in the official trunk, people had
> to use personal svn branches and now teams like plasma think about
> setup integration repos. That sounds weird, you usually use these
> extra branches for huge stuff you don't want to put in trunk right now
> (like big refactoring, or research) not for every little features or
> improvements projects want to push. To me the term "trunk" means it's
> always open to features. I'm sure the Plasma need is not alone and we
> will see these integration repos pop for not particular reason and
> will mess up the history (with merge commit), make the checkout
> complicated for people to use vanilla and make the KDE project
> complicated to understand.
>
> I looked around and all projects using git I've tried (and I'm not
> saying I covered all :D) have a trunk always open to features. Ok it's
> not as complicated/big as KDE but still.
>
> Perhaps I miss a point here so if it's the case, could you please tell me?
>
> I'm trying to see if our workflow could be improved.
>
> Thanks.
>




More information about the kde-core-devel mailing list