[Dev] [openssl] upstream branch update

Whiteman, John L john.l.whiteman at intel.com
Tue Oct 21 22:53:32 GMT 2014

-----Original Message-----
From: Markus Lehtonen [mailto:markus.lehtonen at linux.intel.com]
Sent: Tuesday, October 21, 2014 4:39 AM
To: Janusz Kozerski
Cc: Whiteman, John L; dev at lists.tizen.org
Subject: Re: [Dev] [openssl] upstream branch update


On Tue, 2014-10-21 at 10:57 +0200, Janusz Kozerski wrote:
> Hi John,
> Do you think that it would be better to keep current history of
> upstream branch and cherry-pick upstream history from version 1.0.1h
> to 1.0.1j (as I did on my
> sandbox) or overwrite whole upstream branch with upstream history (force 
> push)?

Please, at least do not overwrite existing upstream/* tags.

One way would be just to merge the real upstream git version (v1.0.1j) into 
the existing upstream branch. This would not break the git history.
Then, in future you'd only need to git-merge new upstream versions into the 
upstream branch. This would preserve the real upstream Git history (with the 
same commit ids than in the upstream git) and avoid cherry-picking.

You can also consider importing upstream release tarballs as before, but, with 
using the --upstream-vcs-tag option that I mentioned in my previous email.

[JOHN]:  Either one is fine although the first choice is quicker without the 
download hassle we are doing now.

> And second question: Are merges from upstream branch to tizen branch
> OK? Do we want to merge upstream to tizen, or we want to keep linear
> history and cherry-pick commits from upstream to tizen?

In the current maintenance model version bumps should be done by rebasing the 
tizen branch on the desired upstream version. Otherwise the GBS patch 
generation will not function as desired (it'll generate one big diff instead 
of individual one-per-commit patches).

[JOHN]:  Yes.  Keep upstream pristine with our patches in Tizen branch applied 
after rebase.


> On 2014-10-20 19:10:43, Whiteman, John L wrote:
> > Hi Janusz,
> >
> > I'm fine with the second approach.  Other upstream packages are
> > already doing it and the history can be useful.
> >
> > Best Regards,
> >
> > John
> >
> > -----Original Message-----
> > From: Janusz Kozerski [mailto:j.kozerski at samsung.com]
> > Sent: Monday, October 20, 2014 6:38 AM
> > To: dev at lists.tizen.org
> > Cc: Tomasz Swierczek; Bartlomiej Grzelewski; Whiteman, John L;
> > Demeter, Michael
> > Subject: [openssl] upstream branch update
> >
> > Hi All,
> >
> > I've seen that on platform/upstream/openssl repository on upstream
> > branch, changes are pulled from upstream as a one big blob of code.
> > Wouldn't be better if we pull commits from upstream as they are? We
> > can have full git history instead of these blobs.
> >
> > I've pushed to a review a commit with update to 1.0.1j in existing
> > convenction.
> > https://review.tizen.org/gerrit/#/c/29027/1
> >
> > I've also prepared a sandbox branch with the same upstream changes
> > (with full git history) rebased on tizen.org upstream branch:
> > https://review.tizen.org/gerrit/gitweb?p=platform%2Fupstream%2Fopens
> > sl
> > .git;
> > a
> > =sho
> > rtlog;h=refs%2Fheads%2Fsandbox%2Fjkozerski%2Fupstream
> >
> > We should choose one way of moving changes from upstream.
> > We should do the same for tizen branch.
> >
> > BR,
> > Janusz Kozerski
> >
> >
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6664 bytes
Desc: not available
URL: <http://lists.tizen.org/pipermail/dev/attachments/20141021/e03eecd9/attachment-0001.p7s>

More information about the Dev mailing list