[Development] requesting an own 4.8-blackberry10 branch on gitorious

Peter Hartmann phartmann at rim.com
Tue Dec 18 19:54:37 CET 2012

On 12/18/2012 07:13 PM, Oswald Buddenhagen wrote:
> On Tue, Dec 18, 2012 at 03:54:20PM +0100, Peter Hartmann wrote:
>> Thanks for setting up the branch; however, would it be possible to get a
>> 4.8-blackberry10 branch (without reference to the patch release number)?
>> We are not really releasing our own versions of 4.8.4, 4.8.5 etc., but
>> have our own release cycle for NDK and device images, which is not
>> related to the Qt 4 release cycle in any way.
> this is immaterial. you are at some point merging from upstream, which is
> also when you should "rebase" your version number. this thinking is also
> reflected in vladimir's questions about the versioning.
> also, consider that users want to think in terms of "upstream release +
> minimal delta", not "rolling release based on older upstream". this is
> predestined for a rebase workflow. also, for actually upstreaming your
> patches, you need to rebase them anyway. latest when you have conflicts,
> you'll really "enjoy" using a non-rebased branch (because you can
> resolve twice or thrice - once to merge upstream, once to submit
> upstream, and in the worst case once more to merge back the upstreamed
> version) - and after some time you'll have a history with conflicted
> merges and duplicated commits all over the place, where it's really hard
> to find out where something comes from and what was already upstreamed.
> given the low number of unmergable vendor patches you are aiming at,
> you'd really do yourself and everyone else a favor by rebasing.
> but if you are the s/m type, you can have your long-living vendor
> branch. ;)

You are completely right about rebasing - that is exactly what we do 
currently: We rebase our internal branch on top of the upstream 4.8 
branch regularly (at least once a week). Where I don't follow you is why 
we would need several branches, each one based on a patch release, for 
that; IMO we just need one branch (4.8-blackberry10) that we can rebase 
periodically on top of the upstream 4.8 branch.

So yes, long-living vendor branch please :)


>> Also (nitpicking), maybe the suffix should be "-blackberry10" instead of
>> "-bb10", because I guess not everybody knows what "bb10" stands for.
> somebody who doesn't know it wouldn't care about that branch to start
> with - and most our branch names are not exactly self-explanatory to the
> uninitiated.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

More information about the Development mailing list