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

Turunen Tuukka Tuukka.Turunen at digia.com
Wed Dec 19 12:14:31 CET 2012

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.



>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).
>> _______________________________________________
>> 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

More information about the Development mailing list