[Qt-creator] [Dev] Qt Creator Submit Policies

[Nicolas Arnaud-Cormos]

On Tuesday 08 November 2011 16:54:16 eike.ziller at nokia.com wrote:
> On 8 Nov 2011, at 11:48, ext Nicolas Arnaud-Cormos wrote:
> > On Tuesday 08 November 2011 11:35:42 eike.ziller at nokia.com wrote:
> >> On 4 Nov 2011, at 20:57, ext Nicolas Arnaud-Cormos wrote:
> >>> On Friday 04 November 2011 16:44:23 Oswald Buddenhagen wrote:
> >>>> On 11/04/11 08:32, ext eike.ziller at nokia.com wrote:
> >>>>> I basically see these possible ways to create separate "branches":
> >>>>> 
> >>>>> 1) A real git branch in gerrit's qt-creator/qt-creator
> >>>>> That would be beside the master&  release branches. *Everyone*
> >>>>> pulling Qt Creator automatically pulls these too, so I'd say they
> >>>>> must be very limited. Or perhaps we shouldn't use them at all for
> >>>>> "topic branches". If we do use them, we need some sort of policy
> >>>>> *what* may be there, and I'd say a maintainer must agree.
> >>>> 
> >>>> what's wrong with everyone pulling the branches?
> >>> 
> >>> Personnaly, that's the solution I prefer this one, as it allows more
> >>> people to discover the branch and maybe more people to contribute to
> >>> it.
> >>> 
> >>> If it's not the way to go, then the wip/clang branch should be moved.
> >> 
> >> Sure, wip/clang will be made to follow whatever we decide on.
> > 
> > We should probably move this discussion to the development mailing list,
> > as it is the same problem for Qt.
> 
> I also grabbed Marius on IRC, and it looks like using "real" git branches
> was originally planned to be used for "feature branches" (as mentioned in
> http://wiki.qt-project.org/Branch_Guidelines) I suppose we'll find out if
> it scales / if we need something that scales better. Also, I've found out
> that the term "topic branch" is already used in gerrit for something
> different (== series of commits that belong together and should be
> reviewed as a whole). The term used for Qt seems to be "feature" branch,
> so I'd go for that term for the Qt Creator "submit policies" as well.
> 
> So, trying to summarize :) we'd have the following:
> 
> Feature branches are git branches starting with wip/* in mainline on
> gerrit. Restricted to work that the respective maintainer agreed on would
> be something that could be merged into master later (if it manages to come
> into sufficient state). Maintainer has final "control", also about when a
> topic branch is removed again (after merging, or if it goes stale).

Thanks for taking care of it.

So any feature that needs a lot of commits or cooperation between different 
people, a new branch should be created. Only maintainer can create branches 
(make sense).
Seems like a feature branch will need a maintainer to look at it, to accept 
the commits. That's the only drawback I can see, as it would add more work to 
maintainers, but at the same time it will ease the merge into master (since 
the code will be already reviewed by a maintainer).

I don't expect tons of feature branches, it should be manageable.

Nicolas

-- 
Nicolas Arnaud-Cormos | nicolas.arnaud-cormos at kdab.com | Senior Software 
Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions