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

[eike.ziller at nokia.com]

I have updated http://wiki.qt-project.org/Qt_Creator_Submit_Policies with additional information about feature branches.

++ Eike

On 8 Nov 2011, at 22:07, ext Nicolas Arnaud-Cormos wrote:

> 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

-- 
Eike Ziller
Principal Software Engineer

Nokia, Qt Development Frameworks

Nokia gate5 GmbH
Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany
Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B
Umsatzsteueridentifikationsnummer: DE 812 845 193
Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori