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 > >> <samer.el- 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 *-------*-----*-------*--------*-----------*------*----*------> > >> \ \ \ / > >> \ \ \ / > >> *-*-*-----------------*---*--------*------ *-*-*-* > >> 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 <jiaxin...@intel.com>; 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 > >> 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
