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

[Peter Hartmann]

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

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.