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

[Turunen Tuukka]

On 19.12.2012 13.08, "Peter Hartmann" <phartmann at rim.com> wrote:

>
>On 12/18/2012 10:06 PM, Oswald Buddenhagen wrote:
>> (...)
>> oh. eh. this is somewhat more extreme than expected. in fact, your
>> branch is everything *but* a long-living branch - it's basically a
>> scratch branch which is recreated every few days. the problem with
>> rebasing is that you "detach" the actual history, so your tags are
>> floating in limbo (provided you make tags at all). that's why i
>> suggested a branch per upstream release. but if you rebase that often,
>> this becomes pointless of course (you'd need a separate branch per
>> rebase).
>>
>> there you have your 4.8-bb10 branch where *only* direct pushing (incl.
>> forced pushes) is enabled.
>> i'll leave it at noting that this is somewhat weird, and that "the
>> project" may still decide that this doesn't belong into the upstream
>> repo.
>
>Thanks for creating the branch. If nobody objects within the next days,
>I will start using it...

We will get more understanding how this goes when you use it. It is then
easier to see what is the best practice for vendor branches.


Yours,

		Tuukka


>
>To clarify: We rebase often on top of upstream because that is where
>KDAB's and our bug fixes go. Our bug fixes go there because several
>times now we had a situation where a commit was made in the internal
>repo, then internal teams started relying on it; at some point later
>upstream review turned out "you cannot do it like that". Then we are
>stuck with a bad internal commit, and resolving such a situation takes a
>lot of effort. So we try to upstream everything as early as possible.
>
>Also, practice has shown that the 4.8 branch is quite stable, and we
>want to get all new commits in early (e.g. security issue, OpenSSL BC
>problem). I found that rebasing is just easier here than cherry-picking
>most of the changes manually.
>Every now and then we need to revert a commit or so, but so far issues
>has been caught by our (unfortunately still internal) CI system. I
>cannot remember one case where a bad regression slipped into our device
>builds so far (though I guess this is more due to the fact that 4.8 is
>stable rather than our CI system being complete).
>
>So if somebody knows how to improve the process taking everything
>mentioned above into account, I am all ears. And I am aware of the fact
>that we are re-writing history (and we currently have no tags).
>
>Peter
>
>
>> _______________________________________________
>> 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.
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development