Re: [edk2] edk2-staging/HTTPS-TLS

[Laszlo Ersek]

On 06/08/16 12:08, David Woodhouse wrote:
> On Thu, 2016-05-19 at 10:30 +0200, Laszlo Ersek wrote:
>>
>> master final merge
>> *---*-*---**---*--**-->
>>  \ \\ /
>>   \ \\   /
>>*-*-*-[discont.]  *-*-*-[discont.] *-*-*-*
>>feature   rebased feature  rebased feature
>>
>>
>> 1.2. Merging. It has the benfit that your development history on the
>> feature (staging) branch will be preserved in edk2 master too. 
> 
> Do not underestimate this benefit. When you are rebasing a complex
> piece of work, and changes in master have affected things which it
> interacts with (like OpenSSL being changed and updated), there is a
> *distinct* possibility that during one of the rebases, you introduce a
> bug. Something that *did* work when you originally wrote your code, now
> no longer works.
> 
> And because you rebased and the old discontinued branches are lost in
> the mists of time (and no longer reachable from the version control
> history), the effect is basically that it *never* worked. You're making
> it look like you committed code that was broken from day one.
> 
> So six months down the line when you realise that some specific corner
> case is broken, and you think "oh, I could have *sworn* I tested that",
> and you go back with all the tools like git-bisect to find where the
> breakage occurred, you're screwed because the history doesn't reflect
> reality.
> 
> If you rebase, you are not using the version control system as it is
> intended to be used. You are wilfully *damaging* the history, and you
> do so at your peril.
> 
>> On the other hand, you have to be careful about the frequency of
>> master-to-staging merges. If you do it very frequently, you'll end up
>> with a complex history.
> 
> Conversely... do not *overestimate* the relevance of a "complex
> history". History is non-linear and contains merged. That is an
> accurate representation of what happened, which is what a version
> control system exists to report.
> 
> You'll mostly neither notice nor care even if you do a gratuitous merge
> from master into your topic branch every day. It just annoys the neat-
> freaks, that's all. So sure, merge back from master only when you
> *need* to. But don't lose sleep over it.
> 
>> In the Linux community, merging is preferred, and a master-to-topic
>> merge is advised whenever the master branch receives a feature or a
>> bugfix that is important for the topic branch as well. That is, no
>> spurious merges.
> 
> That's the norm for basically everyone who is using the version control
> system as it is intended. There are some exceptions, but they're mostly
> doing odd things like pretending git is svn (as edk2 currently is, but
> hopefully not for *too* much longer).

FWIW, I too feel that for such long-living feature branches like
HTTPS-TLS, merging is preferable (both for periodic master-to-feature
syncs, and for the final feature-to-master incorporation). The risk for
rebases to regress the (presumably many and finicky) patches on the
feature branch is just too high otherwise -- the longer the feature
development, the higher the risk, IMO.

Just my two cents anyway -- the decision is ultimately up to the
HTTPS-TLS developers, it's their code and work. :)

Thanks
Laszlo

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] edk2-staging/HTTPS-TLS

[David Woodhouse]

On Thu, 2016-05-19 at 10:30 +0200, Laszlo Ersek wrote:
> 
> master final merge
> *---*-*---**---*--**-->
>  \ \    \ /
>   \ \    \   /
>    *-*-*-[discont.]  *-*-*-[discont.] *-*-*-*
>    feature   rebased feature  rebased feature
> 
> 
> 1.2. Merging. It has the benfit that your development history on the
> feature (staging) branch will be preserved in edk2 master too. 

Do not underestimate this benefit. When you are rebasing a complex
piece of work, and changes in master have affected things which it
interacts with (like OpenSSL being changed and updated), there is a
*distinct* possibility that during one of the rebases, you introduce a
bug. Something that *did* work when you originally wrote your code, now
no longer works.

And because you rebased and the old discontinued branches are lost in
the mists of time (and no longer reachable from the version control
history), the effect is basically that it *never* worked. You're making
it look like you committed code that was broken from day one.

So six months down the line when you realise that some specific corner
case is broken, and you think "oh, I could have *sworn* I tested that",
and you go back with all the tools like git-bisect to find where the
breakage occurred, you're screwed because the history doesn't reflect
reality.

If you rebase, you are not using the version control system as it is
intended to be used. You are wilfully *damaging* the history, and you
do so at your peril.

> On the other hand, you have to be careful about the frequency of
> master-to-staging merges. If you do it very frequently, you'll end up
> with a complex history.

Conversely... do not *overestimate* the relevance of a "complex
history". History is non-linear and contains merged. That is an
accurate representation of what happened, which is what a version
control system exists to report.

You'll mostly neither notice nor care even if you do a gratuitous merge
from master into your topic branch every day. It just annoys the neat-
freaks, that's all. So sure, merge back from master only when you
*need* to. But don't lose sleep over it.

> In the Linux community, merging is preferred, and a master-to-topic
> merge is advised whenever the master branch receives a feature or a
> bugfix that is important for the topic branch as well. That is, no
> spurious merges.

That's the norm for basically everyone who is using the version control
system as it is intended. There are some exceptions, but they're mostly
doing odd things like pretending git is svn (as edk2 currently is, but
hopefully not for *too* much longer).


-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] edk2-staging/HTTPS-TLS

[El-Haj-Mahmoud, Samer]

Thanks Jiaxin. I will pull the code and let you know if I run into issues


-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com] 
Sent: Tuesday, May 24, 2016 10:17 PM
To: El-Haj-Mahmoud, Samer ; 
edk2-devel@lists.01.org
Subject: RE: edk2-staging/HTTPS-TLS

Finished sync the branch from EDK2 master.

Thanks.
Jiaxin


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> El- Haj-Mahmoud, Samer
> Sent: Thursday, May 19, 2016 6:10 AM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Subject: [edk2] edk2-staging/HTTPS-TLS
> 
> Jiaxin,
> 
> The HTTPs-TLS branch is behind EDK2 master, and they are quite a few 
> conflicts to try to keep up with both. Can you please sync the branch 
> from
> EDK2 master?
> 
> Thanks,
> --Samer
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] edk2-staging/HTTPS-TLS

[Wu, Jiaxin]

Finished sync the branch from EDK2 master.

Thanks.
Jiaxin


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of El-
> Haj-Mahmoud, Samer
> Sent: Thursday, May 19, 2016 6:10 AM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Subject: [edk2] edk2-staging/HTTPS-TLS
> 
> Jiaxin,
> 
> The HTTPs-TLS branch is behind EDK2 master, and they are quite a few
> conflicts to try to keep up with both. Can you please sync the branch from
> EDK2 master?
> 
> Thanks,
> --Samer
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] edk2-staging/HTTPS-TLS

[Wu, Jiaxin]

Thanks all of your points. So, option 1 is preferred (Keep the liner commit 
history). And I agree to regular sync edk2-staging/master to latest edk2/master 
automatically, but not for each feature branch's rebase.

Jordan,
If no objection, can you help to set up this regular sync between 
edk2-staging/master and edk2/master? If so, you can avoid the frequency request.

Samer,
I will resolve the conflicts once the regular sync finished.

Thanks.
Jiaxin


> -Original Message-
> From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com]
> Sent: Thursday, May 19, 2016 9:27 PM
> To: Laszlo Ersek <ler...@redhat.com>; Gao, Liming <liming@intel.com>;
> Wu, Jiaxin <jiaxin...@intel.com>; Li, Ruth <ruth...@intel.com>; Ye, Ting
> <ting...@intel.com>; Long, Qin <qin.l...@intel.com>; edk2-
> de...@lists.01.org <edk2-de...@ml01.01.org>; Justen, Jordan L
> <jordan.l.jus...@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; Leif Lindholm (Linaro address)
> <leif.lindh...@linaro.org>
> Subject: RE: [edk2] edk2-staging/HTTPS-TLS
> 
> I do have some experience maintaining my branches (in other projects) that
> eventually get submitted as pull requests to a master. And I always find it
> easier to keep my branch in sync by doing frequent merge form master. I
> agree that it probably makes more sense to do this a couple of times a week
> (or so) manually, and resolve any merge conflicts, than try to automate it.
> 
> At this point, I am working on enabling the HTTPS/TLS feature, but I need to
> do so in a code base that is up-to-date with EDK2 master. So the main issue I
> have is merging from (the now falling behind) HTTPS/TLS branch into my
> code base (which is tracking EDK2). As Laszlo said, it is already getting mad
> because of all of the HTTP fixes in EDK2.
> 
> Thanks,
> --Samer
> 
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, May 19, 2016 5:51 AM
> To: Gao, Liming <liming@intel.com>; Wu, Jiaxin <jiaxin...@intel.com>;
> El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>; Li, Ruth
> <ruth...@intel.com>; Ye, Ting <ting...@intel.com>; Long, Qin
> <qin.l...@intel.com>; edk2-devel@lists.01.org <edk2-de...@ml01.01.org>;
> Justen, Jordan L <jordan.l.jus...@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; Leif Lindholm (Linaro address)
> <leif.lindh...@linaro.org>
> Subject: Re: [edk2] edk2-staging/HTTPS-TLS
> 
> On 05/19/16 11:53, Gao, Liming wrote:
> > Ersek:
> > I remember we discuss Rebase or Merge before. The conclusion is to
> > keep the liner history in edk2 project. So, I think rebase is better.
> 
> Okay.
> 
> > If we choose option 1, I suggest to setup mirror task in server and
> > auto run regular sync. If the confliction happens, it sends the mail
> > to edk dev list and let owner follow up.
> 
> Hmm... I'm not sure about an automated rebase. I always have a number of
> downstream branches (in my private repo) that I rebase almost every day to
> new master.
> 
> However, occasionally I'm so deep in work that I don't want to rebase for a
> week, for example. An automated rebase would be very annoying in such
> situations, when I'm in the middle of shuffling around my patches.
> 
> I think it's the owner's responsibility after all. If they are fine with an
> automated rebase, so be it; but the automatism should be possible to disable.
> 
> Thanks
> Laszlo
> 
> > Thanks
> > Liming
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> >> Of Laszlo Ersek
> >> Sent: Thursday, May 19, 2016 4:31 PM
> >> To: Wu, Jiaxin <jiaxin...@intel.com>; El-Haj-Mahmoud, Samer
> >> ; Li, Ruth <ruth...@intel.com>; Ye,
> >> Ting <ting...@intel.com>; Long, Qin <qin.l...@intel.com>; edk2-
> >> de...@lists.01.org <edk2-de...@ml01.01.org>; Justen, Jordan L
> >> <jordan.l.jus...@intel.com>; Kinney, Michael D
> >> <michael.d.kin...@intel.com>; Leif Lindholm (Linaro address)
> >> <leif.lindh...@linaro.org>
> >> Subject: Re: [edk2] edk2-staging/HTTPS-TLS
> >>
> >> On 05/19/16 05:35, Wu, Jiaxin wrote:
> >>> Hi all,
> >>> There are two ways to sync HTTPS-TLS branch with EDK2 master:
> >>>
> >>> 1. Sync all changes in EDK2 master to branch by rebasing the whole
> >>> feature branch. Need frequency request to sync edk2-staging/master
> >>> to latest edk2/master. This way can also keep branch code go
> >>> s

Re: [edk2] edk2-staging/HTTPS-TLS

[El-Haj-Mahmoud, Samer]

I do have some experience maintaining my branches (in other projects) that 
eventually get submitted as pull requests to a master. And I always find it 
easier to keep my branch in sync by doing frequent merge form master. I agree 
that it probably makes more sense to do this a couple of times a week (or so) 
manually, and resolve any merge conflicts, than try to automate it.

At this point, I am working on enabling the HTTPS/TLS feature, but I need to do 
so in a code base that is up-to-date with EDK2 master. So the main issue I have 
is merging from (the now falling behind) HTTPS/TLS branch into my code base 
(which is tracking EDK2). As Laszlo said, it is already getting mad because of 
all of the HTTP fixes in EDK2.

Thanks,
--Samer


-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, May 19, 2016 5:51 AM
To: Gao, Liming <liming@intel.com>; Wu, Jiaxin <jiaxin...@intel.com>; 
El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>; Li, Ruth 
<ruth...@intel.com>; Ye, Ting <ting...@intel.com>; Long, Qin 
<qin.l...@intel.com>; edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Justen, 
Jordan L <jordan.l.jus...@intel.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; Leif Lindholm (Linaro address) 
<leif.lindh...@linaro.org>
Subject: Re: [edk2] edk2-staging/HTTPS-TLS

On 05/19/16 11:53, Gao, Liming wrote:
> Ersek:
> I remember we discuss Rebase or Merge before. The conclusion is to 
> keep the liner history in edk2 project. So, I think rebase is better.

Okay.

> If we choose option 1, I suggest to setup mirror task in server and 
> auto run regular sync. If the confliction happens, it sends the mail 
> to edk dev list and let owner follow up.

Hmm... I'm not sure about an automated rebase. I always have a number of 
downstream branches (in my private repo) that I rebase almost every day to new 
master.

However, occasionally I'm so deep in work that I don't want to rebase for a 
week, for example. An automated rebase would be very annoying in such 
situations, when I'm in the middle of shuffling around my patches.

I think it's the owner's responsibility after all. If they are fine with an 
automated rebase, so be it; but the automatism should be possible to disable.

Thanks
Laszlo

> Thanks
> Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
>> Of Laszlo Ersek
>> Sent: Thursday, May 19, 2016 4:31 PM
>> To: Wu, Jiaxin <jiaxin...@intel.com>; El-Haj-Mahmoud, Samer 
>> ; Li, Ruth <ruth...@intel.com>; Ye, 
>> Ting <ting...@intel.com>; Long, Qin <qin.l...@intel.com>; edk2- 
>> de...@lists.01.org <edk2-de...@ml01.01.org>; Justen, Jordan L 
>> <jordan.l.jus...@intel.com>; Kinney, Michael D 
>> <michael.d.kin...@intel.com>; Leif Lindholm (Linaro address) 
>> <leif.lindh...@linaro.org>
>> Subject: Re: [edk2] edk2-staging/HTTPS-TLS
>>
>> On 05/19/16 05:35, Wu, Jiaxin wrote:
>>> Hi all,
>>> There are two ways to sync HTTPS-TLS branch with EDK2 master:
>>>
>>> 1. Sync all changes in EDK2 master to branch by rebasing the whole 
>>> feature branch. Need frequency request to sync edk2-staging/master 
>>> to latest edk2/master. This way can also keep branch code go 
>>> straight with edk2/master.
>>>
>>> 2. Only sync HTTPS/TLS related patches to branch (e.g. HttpDxe 
>>> update). That means to use one stable edk2 tag for 
>>> edk2-staging/HTTPS-TLS branch development. By this way, frequency 
>>> request to sync edk2-staging/master to latest edk2/master can be 
>>> avoided but maybe some bugs fixed in edk2/master can't be synced to 
>>> branch timely.
>>>
>>> Both of them are not easy since it's probable that each updates in
>>> edk2 trunk may cause the conflicts with the HTTPS code (HttpDxe 
>>> driver and CryptyPkg especially).
>>>
>>> Effort is almost. Which one do you prefer?
>>
>> I'm chiming in here not because I have a direct interest in the 
>> HTTPS-TLS feature set, but because this feature branch seems to be 
>> the first real-life test case of edk2-staging. I'd like to add three points.
>>
>> (a) The ultimate goal of a staging branch is to be merged into edk2 
>> master when the feature is complete. If you try to save the effort 
>> now that would be necessary for rebasing the feature branch, you will 
>> go
>> *mad* when you finally want to merge the staging branch into edk2 
>> master. The larger you allow the divergence to grow, the 
>> (non-linearly) harder time you will have when you try to do the final 
>> merge into edk2 master. So, 

Re: [edk2] edk2-staging/HTTPS-TLS

[Laszlo Ersek]

On 05/19/16 11:53, Gao, Liming wrote:
> Ersek:
> I remember we discuss Rebase or Merge before. The conclusion is to
> keep the liner history in edk2 project. So, I think rebase is better.

Okay.

> If we choose option 1, I suggest to setup mirror task in server and
> auto run regular sync. If the confliction happens, it sends the mail
> to edk dev list and let owner follow up.

Hmm... I'm not sure about an automated rebase. I always have a number of
downstream branches (in my private repo) that I rebase almost every day
to new master.

However, occasionally I'm so deep in work that I don't want to rebase
for a week, for example. An automated rebase would be very annoying in
such situations, when I'm in the middle of shuffling around my patches.

I think it's the owner's responsibility after all. If they are fine with
an automated rebase, so be it; but the automatism should be possible to
disable.

Thanks
Laszlo

> Thanks
> Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Thursday, May 19, 2016 4:31 PM
>> To: Wu, Jiaxin <jiaxin...@intel.com>; El-Haj-Mahmoud, Samer > haj-mahm...@hpe.com>; Li, Ruth <ruth...@intel.com>; Ye, Ting
>> <ting...@intel.com>; Long, Qin <qin.l...@intel.com>; edk2-
>> de...@lists.01.org <edk2-de...@ml01.01.org>; Justen, Jordan L
>> <jordan.l.jus...@intel.com>; Kinney, Michael D
>> <michael.d.kin...@intel.com>; Leif Lindholm (Linaro address)
>> <leif.lindh...@linaro.org>
>> Subject: Re: [edk2] edk2-staging/HTTPS-TLS
>>
>> On 05/19/16 05:35, Wu, Jiaxin wrote:
>>> Hi all,
>>> There are two ways to sync HTTPS-TLS branch with EDK2 master:
>>>
>>> 1. Sync all changes in EDK2 master to branch by rebasing the whole
>>> feature branch. Need frequency request to sync edk2-staging/master to
>>> latest edk2/master. This way can also keep branch code go straight
>>> with edk2/master.
>>>
>>> 2. Only sync HTTPS/TLS related patches to branch (e.g. HttpDxe
>>> update). That means to use one stable edk2 tag for
>>> edk2-staging/HTTPS-TLS branch development. By this way, frequency
>>> request to sync edk2-staging/master to latest edk2/master can be
>>> avoided but maybe some bugs fixed in edk2/master can't be synced to
>>> branch timely.
>>>
>>> Both of them are not easy since it's probable that each updates in
>>> edk2 trunk may cause the conflicts with the HTTPS code (HttpDxe
>>> driver and CryptyPkg especially).
>>>
>>> Effort is almost. Which one do you prefer?
>>
>> I'm chiming in here not because I have a direct interest in the
>> HTTPS-TLS feature set, but because this feature branch seems to be the
>> first real-life test case of edk2-staging. I'd like to add three points.
>>
>> (a) The ultimate goal of a staging branch is to be merged into edk2
>> master when the feature is complete. If you try to save the effort now
>> that would be necessary for rebasing the feature branch, you will go
>> *mad* when you finally want to merge the staging branch into edk2
>> master. The larger you allow the divergence to grow, the (non-linearly)
>> harder time you will have when you try to do the final merge into edk2
>> master. So, the trick is to stay sensibly close as possible to edk2
>> master on the staging branch.
>>
>> For this reason, option (1) is very strongly preferable. Option (2) --
>> which is called "cherry picking" or "backporting" -- is really only an
>> option for branches that are never meant to be merged back into the
>> master branch. Given that HTTPS-TLS is not such a downstream branch
>> (instead, it is a development, topic branch), option (2) doesn't apply.
>>
>> (b) For option (1), there are actually two methods, rebasing and merging:
>>
>> 1.1. Rebasing. It has the drawback that it throws away your prior
>> development history on the feature (staging) branch. Many people don't
>> like this. On the other hand, you can do it as frequently as you like,
>> without creating a mess of commit history.
>>
>> Here's a diagram:
>>
>> master final merge
>> *---*-*---**---*--**-->
>>  \ \\ /
>>   \ \\   /
>>*-*-*-[discont.]  *-*-*-[discont.] *-*-*-*
>>feature   rebased feature  rebased feature
>>
>&

Re: [edk2] edk2-staging/HTTPS-TLS

[Gao, Liming]

Ersek:
  I remember we discuss Rebase or Merge before. The conclusion is to keep the 
liner history in edk2 project. So, I think rebase is better. If we choose 
option 1, I suggest to setup mirror task in server and auto run regular sync. 
If the confliction happens, it sends the mail to edk dev list and let owner 
follow up. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Thursday, May 19, 2016 4:31 PM
> To: Wu, Jiaxin <jiaxin...@intel.com>; El-Haj-Mahmoud, Samer  haj-mahm...@hpe.com>; Li, Ruth <ruth...@intel.com>; Ye, Ting
> <ting...@intel.com>; Long, Qin <qin.l...@intel.com>; edk2-
> de...@lists.01.org <edk2-de...@ml01.01.org>; Justen, Jordan L
> <jordan.l.jus...@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; Leif Lindholm (Linaro address)
> <leif.lindh...@linaro.org>
> Subject: Re: [edk2] edk2-staging/HTTPS-TLS
> 
> On 05/19/16 05:35, Wu, Jiaxin wrote:
> > Hi all,
> > There are two ways to sync HTTPS-TLS branch with EDK2 master:
> >
> > 1. Sync all changes in EDK2 master to branch by rebasing the whole
> > feature branch. Need frequency request to sync edk2-staging/master to
> > latest edk2/master. This way can also keep branch code go straight
> > with edk2/master.
> >
> > 2. Only sync HTTPS/TLS related patches to branch (e.g. HttpDxe
> > update). That means to use one stable edk2 tag for
> > edk2-staging/HTTPS-TLS branch development. By this way, frequency
> > request to sync edk2-staging/master to latest edk2/master can be
> > avoided but maybe some bugs fixed in edk2/master can't be synced to
> > branch timely.
> >
> > Both of them are not easy since it's probable that each updates in
> > edk2 trunk may cause the conflicts with the HTTPS code (HttpDxe
> > driver and CryptyPkg especially).
> >
> > Effort is almost. Which one do you prefer?
> 
> I'm chiming in here not because I have a direct interest in the
> HTTPS-TLS feature set, but because this feature branch seems to be the
> first real-life test case of edk2-staging. I'd like to add three points.
> 
> (a) The ultimate goal of a staging branch is to be merged into edk2
> master when the feature is complete. If you try to save the effort now
> that would be necessary for rebasing the feature branch, you will go
> *mad* when you finally want to merge the staging branch into edk2
> master. The larger you allow the divergence to grow, the (non-linearly)
> harder time you will have when you try to do the final merge into edk2
> master. So, the trick is to stay sensibly close as possible to edk2
> master on the staging branch.
> 
> For this reason, option (1) is very strongly preferable. Option (2) --
> which is called "cherry picking" or "backporting" -- is really only an
> option for branches that are never meant to be merged back into the
> master branch. Given that HTTPS-TLS is not such a downstream branch
> (instead, it is a development, topic branch), option (2) doesn't apply.
> 
> (b) For option (1), there are actually two methods, rebasing and merging:
> 
> 1.1. Rebasing. It has the drawback that it throws away your prior
> development history on the feature (staging) branch. Many people don't
> like this. On the other hand, you can do it as frequently as you like,
> without creating a mess of commit history.
> 
> Here's a diagram:
> 
> master final merge
> *---*-*---**---*--**-->
>  \ \\ /
>   \ \\   /
>*-*-*-[discont.]  *-*-*-[discont.] *-*-*-*
>feature   rebased feature  rebased feature
> 
> 
> 1.2. Merging. It has the benfit that your development history on the
> feature (staging) branch will be preserved in edk2 master too. On the
> other hand, you have to be careful about the frequency of
> master-to-staging merges. If you do it very frequently, you'll end up
> with a complex history.
> 
> In the Linux community, merging is preferred, and a master-to-topic
> merge is advised whenever the master branch receives a feature or a
> bugfix that is important for the topic branch as well. That is, no
> spurious merges.
> 
> Here's a diagram:
> 
> master final merge
>back into master
> *---*-*---**---*--**-->
>  \ \\ /
>   \ \

Re: [edk2] edk2-staging/HTTPS-TLS

[Laszlo Ersek]

On 05/19/16 05:35, Wu, Jiaxin wrote:
> Hi all,
> There are two ways to sync HTTPS-TLS branch with EDK2 master:
> 
> 1. Sync all changes in EDK2 master to branch by rebasing the whole
> feature branch. Need frequency request to sync edk2-staging/master to
> latest edk2/master. This way can also keep branch code go straight
> with edk2/master.
> 
> 2. Only sync HTTPS/TLS related patches to branch (e.g. HttpDxe
> update). That means to use one stable edk2 tag for
> edk2-staging/HTTPS-TLS branch development. By this way, frequency
> request to sync edk2-staging/master to latest edk2/master can be
> avoided but maybe some bugs fixed in edk2/master can't be synced to
> branch timely.
> 
> Both of them are not easy since it's probable that each updates in
> edk2 trunk may cause the conflicts with the HTTPS code (HttpDxe
> driver and CryptyPkg especially).
> 
> Effort is almost. Which one do you prefer?

I'm chiming in here not because I have a direct interest in the
HTTPS-TLS feature set, but because this feature branch seems to be the
first real-life test case of edk2-staging. I'd like to add three points.

(a) The ultimate goal of a staging branch is to be merged into edk2
master when the feature is complete. If you try to save the effort now
that would be necessary for rebasing the feature branch, you will go
*mad* when you finally want to merge the staging branch into edk2
master. The larger you allow the divergence to grow, the (non-linearly)
harder time you will have when you try to do the final merge into edk2
master. So, the trick is to stay sensibly close as possible to edk2
master on the staging branch.

For this reason, option (1) is very strongly preferable. Option (2) --
which is called "cherry picking" or "backporting" -- is really only an
option for branches that are never meant to be merged back into the
master branch. Given that HTTPS-TLS is not such a downstream branch
(instead, it is a development, topic branch), option (2) doesn't apply.

(b) For option (1), there are actually two methods, rebasing and merging:

1.1. Rebasing. It has the drawback that it throws away your prior
development history on the feature (staging) branch. Many people don't
like this. On the other hand, you can do it as frequently as you like,
without creating a mess of commit history.

Here's a diagram:

master final merge
*---*-*---**---*--**-->
 \ \\ /
  \ \\   /
   *-*-*-[discont.]  *-*-*-[discont.] *-*-*-*
   feature   rebased feature  rebased feature


1.2. Merging. It has the benfit that your development history on the
feature (staging) branch will be preserved in edk2 master too. On the
other hand, you have to be careful about the frequency of
master-to-staging merges. If you do it very frequently, you'll end up
with a complex history.

In the Linux community, merging is preferred, and a master-to-topic
merge is advised whenever the master branch receives a feature or a
bugfix that is important for the topic branch as well. That is, no
spurious merges.

Here's a diagram:

master final merge
   back into master
*---*-*---**---*--**-->
 \ \\ /
  \ \\   /
   *-*-*-*---**-- *-*-*-*
   feature   ^ merge from master  ^ another merge
 triggered by from master
 important new stuff
 in master

I think that for edk2 staging branches, both 1.1. (= rebasing staging to
master) and 1.2. (= merging master into staging) are appropriate. Both
can facilitate the final merge back into master.

Option (2) (= cherry-picking patches from master to staging) is *not*
appropriate.

Thanks
Laszlo


> 
> Thanks.
> Jiaxin
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of El-
>> Haj-Mahmoud, Samer
>> Sent: Thursday, May 19, 2016 6:10 AM
>> To: Wu, Jiaxin ; edk2-devel@lists.01.org
>> Subject: [edk2] edk2-staging/HTTPS-TLS
>>
>> Jiaxin,
>>
>> The HTTPs-TLS branch is behind EDK2 master, and they are quite a few
>> conflicts to try to keep up with both. Can you please sync the branch from
>> EDK2 master?
>>
>> Thanks,
>> --Samer
>>
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

___
edk2-devel mailing list

Re: [edk2] edk2-staging/HTTPS-TLS

[Long, Qin]

Personally, I prefer to use the second option for this kind of sync-up. 
Of cause, we need to have good senses about which updates will impact this 
staging feature. 


Best Regards & Thanks,
LONG, Qin

> -Original Message-
> From: Wu, Jiaxin
> Sent: Thursday, May 19, 2016 11:35 AM
> To: El-Haj-Mahmoud, Samer; Li, Ruth; Ye, Ting; Long, Qin; edk2-
> de...@lists.01.org
> Subject: RE: edk2-staging/HTTPS-TLS
> 
> Hi all,
> There are two ways to sync HTTPS-TLS branch with EDK2 master:
> 
> 1. Sync all changes in EDK2 master to branch by rebasing the whole feature
> branch. Need frequency request to sync edk2-staging/master to latest
> edk2/master. This way can also keep branch code go straight with
> edk2/master.
> 
> 2. Only sync HTTPS/TLS related patches to branch (e.g. HttpDxe update). That
> means to use one stable edk2 tag for edk2-staging/HTTPS-TLS branch
> development. By this way, frequency request to sync edk2-staging/master
> to latest edk2/master can be avoided but maybe some bugs fixed in
> edk2/master can't be synced to branch timely.
> 
> Both of them are not easy since it's probable that each updates in edk2 trunk
> may cause the conflicts with the HTTPS code (HttpDxe driver and CryptyPkg
> especially).
> 
> Effort is almost. Which one do you prefer?
> 
> Thanks.
> Jiaxin
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > El- Haj-Mahmoud, Samer
> > Sent: Thursday, May 19, 2016 6:10 AM
> > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > Subject: [edk2] edk2-staging/HTTPS-TLS
> >
> > Jiaxin,
> >
> > The HTTPs-TLS branch is behind EDK2 master, and they are quite a few
> > conflicts to try to keep up with both. Can you please sync the branch
> > from
> > EDK2 master?
> >
> > Thanks,
> > --Samer
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel