[Dev] [openssl] upstream branch update

Janusz Kozerski j.kozerski at samsung.com
Wed Oct 22 10:31:29 GMT 2014


Hi,

On upstream branch I've left the Tizen git history as it was, and I've pushed all upstream commits from version 1.0.1h to 1.0.1j on the top.
I did the same for tizen branch + rebase all tizen-specific commit on the top. I've also sent commit with changing version number to the review.

I think it the best solution.

BR,
Janusz


On 2014-10-22 02:19:32, Whiteman, John L wrote:
> 
> 
> -----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
> 
> Hi,
> 
> 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.
> 
> Thanks,
>   Markus
> 
> 
> > 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%2Fope
> > > ns
> > > 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
> 




More information about the Dev mailing list