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

[eike.ziller at nokia.com]

On 4 Nov 2011, at 16:44, ext 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?

It e.g. depends on how many we will have. Maybe it works out, maybe we'll get a huge centralistic all-in-one monster. My impression was that one of the points of using git was to be able to avoid that from the beginning ;)
We could probably start with "one repo to rule them all", and take according measures if that turns out to be the wrong way.
A mainline repository with lots of branches with barely half-finished experiments, where it is even difficult to say what the scope of each branch actually was supposed to be without looking at the source changes in there (because branch names as the "description" is not sufficient) would be something to definitely avoid IMO.

>> 2) Gerrit project, qt-creator/*
>> I suppose it would be possible to create separate (sub-)projects on gerrit, e.g. qt-creator/scriptplugin or something like that. Since these are really separate git repositories they don't affect people who pull qt-creator/qt-creator. Would be a bit similar to gitorious' repository clones. We should probably still have some sort of creation policy, and maybe also when they'll be removed again. But this could be handled with less restrictions than 1)
>> 
> i don't want that. the gerrit gui is utterly unsuitable for managing it.

I agree that http://codereview.qt-project.org/#admin,projects is not well suited for any management of a larger list.
The same problem would exist when putting everything in a single repo, "git branch -a" isn't a suitable UI either (where it's even not possible to give the branches a longer description).

> i want to enable private namespaces in gerrit where people could push 
> their own stuff to and to optionally have proper gerrit reviews. if we 
> go really overboard, the (to be implemented) early warning system could 
> be invited for compile/test trial runs. the namespace would be 
> refs/personal/<user>/* in the project's mainline repository, so everyone 
> could optionally pull it by explicitly specifying the refs. i need to 
> think of some kind of "expiration policy" to avoid too many dead branches.

Sounds ok-ish if that had a sensible UI then, that is better than a single long list and still allows some discoverability.

>> 3) gitorious clone or clone whereever.
>> Has the advantage of no restriction or policies, but the disadvantages of a) missing discoverability, and b) the "CLA requires you to use a feature branch on Gerrit" point above.
>> 
> the cla point is meant to ensure that everyone contributing something 
> did actually accept the cla and that every commit is authored by the 
> person it claims to be from. that's most easily achieved by requiring 
> people to use gerrit for the incremental work, not only the final 
> publication. but technically there is no reason why the branch could not 
> be external and then the commits would be posted to gerrit one by one by 
> their respective owners. teams who wish to experiment "in private" may 
> prefer this approach.


-- 
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