On 07/23/15 20:57, Jordan Justen wrote: > I queued up the patches you collected:
(What, top posting? "You too, Brutus?" :)) > > https://github.com/tianocore/edk2-svn-offline/commits/master > > Thanks again for collecting them up! Awesome, thank you! Laszlo > > -Jordan > > On 2015-07-23 10:50:14, Laszlo Ersek wrote: >> On 07/23/15 19:31, Jordan Justen wrote: >>> On 2015-07-23 10:04:26, Laszlo Ersek wrote: >>>> On 07/23/15 02:06, Jordan Justen wrote: >>>>> Okay. Based on Laszlo's request, I setup a temporary git repo to >>>>> collect up the changes that should have been committed to svn the past >>>>> week. >>>>> >>>>> https://github.com/tianocore/edk2-svn-offline >>>>> >>>>> So far, I added the 2 commits that made it to svn but didn't get >>>>> mirrored to the git-svn mirror. Let me know if I should add something >>>>> to the branch. >>>>> >>>>> Here's the git commands to setup a new svn-offline remote: >>>>> >>>>> git remote add svn-offline >>>>> https://github.com/tianocore/edk2-svn-offline.git >>>> >>>> ... This was *hard*. >>>> >>>> I reached back to the past on the list (actually, on both lists, old and >>>> new), to a few days before the SF outage started. (Outage start: 16th, I >>>> reached back to the 13th or so.) >>>> >>>> I collected *all* patches from that timeframe that are now ready for >>>> merging (and would already have been merged, if not for the SF outage). >>>> >>>> In total, that's 27 patches. I verified maintainer and/or key package >>>> contributor Reviewed-by tags as the criterion for including a patch or a >>>> series. I also picked up all tags posted as feedback. Sometimes the >>>> maintainer requested trivial changes but gave his R-b immediately; I >>>> effected those changes. Finally, I reformatted a few blatantly >>>> misformatted commit messages, fixed a gcc build error (discussed and >>>> approved on the list), noted my minimal changes, and then added my S-o-b >>>> at the bottom of all patches I rounded up. >>> >>> Thanks Laszlo! >>> >>> One request, can you change the commit message on: >>> "IntelFrameworkModulePkg/GenericBdsLib: remove AcpiS3->S3Save() call" >>> >>> Cc: Yao, Jiewen <jiewen....@intel.com> >>> >>> => >>> >>> Cc: "Yao, Jiewen" <jiewen....@intel.com> >>> >>> or >>> >>> Cc: Jiewen Yao <jiewen....@intel.com> >>> >> >> Aaargh. You noted this earlier, and I fixed it up, actually -- in >> another branch that I did not end up posting, after all. If you recall, >> there was a short interval when this specific patch appeared to be >> rejected, so I prepared a v3 locally, dropping this patch, and slightly >> updating the commit messages of those coming after it. (No other >> changes.) And, I fixed the above Cc on that v3, local branch. >> >> Now, after Jeff discussed the question with Jiewen, Jeff agreed that >> this patch was okay ultimately. So I returned to v2, picked up the tags >> again from the list -- and forgot to redo the CC fix. >> >> In any case, I corrected it now, and force-pushed the rebased branch >> (with no other changes) to the same location. Its head changed from >> dfa837e to 2eb8300. Please re-fetch it. >> >>> Actually, my personal opinion is that Cc entries can be dropped when >>> merging upstream, but I don't have a strong feeling on it. Is there an >>> argument for leaving them? >> >> Yes, I quite like them. It's nice to see who was originally on CC. Also, >> removing them is too much work. :) >> >> And, in the Linux kernel at least, when a patch is cherry-picked to a >> stable branch (or tree), the original participants (author, reviewers, >> Cc's etc) get fresh emails about that fact. That's also nice. >> >> Thanks! >> Laszlo >> >>> >>> -Jordan >>> >>>> You can find the patches in: >>>> >>>> https://github.com/lersek/edk2/commits/merge_this_please >>>> >>>> They are based on top of your svn-offline/master branch (currently at >>>> 53c8704060e9fb4ba5ec2e92a5e6f188a3237ab0, "Daryl has changed positions >>>> and I am taking over maintaining for now."). >>>> >>>> Please *merge* this branch into svn-offline/master -- it will be a >>>> fast-forward, and no merge commit will be created. >>>> >>>> After that, everyone should pull from your "svn-offline/master", and >>>> resume working off that. >>>> >>>> Here's a summary of the patches that I picked up, in order. Any >>>> (trivial) changes I did are marked with "-->". >>>> >>>> [edk2] [PATCH v2 0/6] OvmfPkg: save S3 state at EndOfDxe >>>> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/17384 >>>> Message-Id: <1436892487-17202-1-git-send-email-ler...@redhat.com> >>>> >>>> [edk2] [PATCH v2 0/6] ArmVirtPkg/ArmVirtQemu: support SMBIOS >>>> http://thread.gmane.org/gmane.comp.bios.edk2.devel/144 >>>> Message-Id: <1437477015-31200-1-git-send-email-ler...@redhat.com> >>>> >>>> [edk2] [PATCH] NetworkPkg: Fix bug in IpSecImpl.c caused by missing >>>> parentheses >>>> http://thread.gmane.org/gmane.comp.bios.edk2.devel/23 >>>> Message-Id: <1437109652-26456-1-git-send-email-br...@cran.org.uk> >>>> --> incorporating trivial changes suggested by Siyuan >>>> >>>> [edk2] [PATCH] Maintainers.txt: ARM packages maintainer update >>>> http://thread.gmane.org/gmane.comp.bios.edk2.devel/52 >>>> Message-Id: <1437148284-16942-1-git-send-email-leif.lindh...@linaro.org> >>>> >>>> [edk2] [PATCH] BaseTools/Common: fix heap overrun in ReadMemoryFileLine >>>> () >>>> http://thread.gmane.org/gmane.comp.bios.edk2.devel/56 >>>> Message-Id: <1437157378-31683-1-git-send-email-ard.biesheu...@linaro.org> >>>> >>>> [edk2] [PATCH v2] MdeModulePkg: Remove TransmitReceive() and ActiveChild >>>> dependency >>>> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/17417/focus=94 >>>> Message-Id: <1437359434-11592-1-git-send-email-jiaxin...@intel.com> >>>> >>>> [edk2] [patch] NetworkPkg: Fix the issue EfiPxeBcDhcp()may return wrong >>>> status. >>>> http://thread.gmane.org/gmane.comp.bios.edk2.devel/102 >>>> Message-Id: <6c40a76c-8fd3-454d-87c1-809b086afb94@LUBOZHAN-MOBL.local> >>>> --> updated copyright year as Siyuan asked >>>> >>>> [edk2] [patch] MdeModulePkg: Fix the issue EfiPxeBcDhcp()may return >>>> wrong status. >>>> http://thread.gmane.org/gmane.comp.bios.edk2.devel/101 >>>> Message-Id: <b1f41f78-e42a-46e8-8a10-af9f095f542a@LUBOZHAN-MOBL.local> >>>> --> updated copyright year as Siyuan asked >>>> >>>> [edk2] [Patch] ShellPkg: Fix bad TimeZone (TZ) conversion. >>>> http://thread.gmane.org/gmane.comp.bios.edk2.devel/57 >>>> Message-Id: <0755eef5-682f-454e-a24f-2cc7ca040...@apple.com> >>>> --> synthetized Jaben's R-b from his response in the thread >>>> >>>> [edk2] [patch] MdeModulePkg:Correct the parameter order in match2 sample >>>> opcode >>>> http://thread.gmane.org/gmane.comp.bios.edk2.devel/118 >>>> Message-Id: <1437383587-10968-1-git-send-email-dandan...@intel.com> >>>> >>>> [edk2] [patch] MdeModulePkg:Check the case caused by mismatch >>>> http://thread.gmane.org/gmane.comp.bios.edk2.devel/127 >>>> Message-Id: <1437446204-10520-1-git-send-email-dandan...@intel.com> >>>> >>>> [edk2] [PATCH 0/2] Correct address pointers from AuthVariableLib >>>> http://thread.gmane.org/gmane.comp.bios.edk2.devel/133 >>>> Message-Id: <1437469312-14652-1-git-send-email-star.z...@intel.com> >>>> --> squashed minimal gcc build fixup, approved by Star >>>> >>>> [edk2] [Patch v3] NetworkPkg: Add old IPv4_DEVICE_PATH and >>>> IPv6_DEVICE_PATH support >>>> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/17557 >>>> Message-Id: <e8f0dd84-6256-4591-b772-24a2d79370a4@FANWANG2-MOBL1.local> >>>> --> rewrapped commit message >>>> >>>> [edk2] [Patch v3] MdeModulePkg: Add old IPv4_DEVICE_PATH support for new >>>> IScsiDxe >>>> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/17558 >>>> Message-Id: <78716473-f072-42b8-8468-ea3552320f15@FANWANG2-MOBL1.local> >>>> --> rewrapped commit message >>>> >>>> [edk2] [PATCH] Make AutoGen.h array declaration match AutoGen.c >>>> definition >>>> http://thread.gmane.org/gmane.comp.bios.edk2.devel/179 >>>> Message-Id: <001d01d0c42b$362a15f0$a27e41d0$@notabs.org> >>>> >>>> [edk2] [PATCH] ShellPkg: Fix the ASSERT issue in Shell 'for' loop >>>> http://thread.gmane.org/gmane.comp.bios.edk2.devel/182 >>>> Message-Id: <1437550864-41772-1-git-send-email-shumin....@intel.com> >>>> --> updated commit message as requested by Jaben >>>> >>>> I'm reasonably sure that all ready-to-merge patches have been included. >>>> >>>> I smoke tested the branch with the following command lines (both >>>> building and running): >>>> >>>> build -a X64 -p OvmfPkg/OvmfPkgX64.dsc -D SECURE_BOOT_ENABLE \ >>>> -t GCC48 -b DEBUG >>>> >>>> build -a AARCH64 -t GCC48 -p ArmVirtPkg/ArmVirtQemu.dsc -b DEBUG \ >>>> -D DEBUG_PRINT_ERROR_LEVEL=0x8040004F -D INTEL_BDS \ >>>> -D SECURE_BOOT_ENABLE >>>> >>>> I will respond in each individual thread too. >>>> >>>> Thanks >>>> Laszlo >>>> >>>>> >>>>> -Jordan >>>>> >>>>> Forwarded message from Laszlo Ersek (2015-07-22 13:52:38): >>>>>> On 07/22/15 22:39, Jordan Justen wrote: >>>>>>> On 2015-07-22 12:57:13, Laszlo Ersek wrote: >>>>>>>> On 07/22/15 21:44, Bruce Cran wrote: >>>>>>>>> On 7/22/2015 4:18 AM, Laszlo Ersek wrote: >>>>>>>>>> How about someone creates a temporary branch off the github master >>>>>>>>>> branch, and applies all new patches from the list that have been >>>>>>>>>> reviewed thus far? Then once SVN is back up, the patches from that >>>>>>>>>> git >>>>>>>>>> branch could be committed to SVN by a single person, in one go, >>>>>>>>>> nicely >>>>>>>>>> ordered. >>>>>>>>> >>>>>>>>> Wouldn't a fork be preferable? Anyone can create one, and it doesn't >>>>>>>>> pollute the main repository. >>>>>>>> >>>>>>>> The branch should be owned by an Intel associate, trusted by the entire >>>>>>>> community. Having the same level access as needed by the current main >>>>>>>> git repo / master branch too. The point is that *everyone* should start >>>>>>>> working against this new branch, until SVN returns to life. >>>>>>> >>>>>>> I don't think it is a good idea to temporarily setup an alternate >>>>>>> official 'upstream'. Unlike if we were using git, we can't just push >>>>>>> the branch back to the main server once it comes back online. Instead, >>>>>>> we'll have to use git-svn dcommit, and this will put all the patches >>>>>>> onto a diverged branch. >>>>>> >>>>>> Yes, that's the idea, sort of. Patches would be collected on a >>>>>> non-master branch in git, with the branch being forked off from current >>>>>> master. Once SVN returns, the patches from the special branch would be >>>>>> formatted, applied to a git-svn clone with git-am manually, and then >>>>>> committed with git-svn dcommit. Then these patches would percolate to >>>>>> the git mirror (master branch) as usual, and the temporary / special >>>>>> branch could be simply deleted. >>>>>> >>>>>>> As you suggest, I can see trying to collect up the outstanding >>>>>>> ready-to-merge patches onto a temporary branch so they don't get lost. >>>>>>> Maybe I could just try to collect patches into a svn-offline branch in >>>>>>> my personal repo? I guess we could also put a temporary repo at >>>>>>> github.com/tianocore/edk2-svn-offline... >>>>>> >>>>>> Separate repo, or separate (special, temporary) branch in the current >>>>>> main repo -- they're about the same. So yes, that's the idea. For me all >>>>>> of these solutions are acceptable, as long as there is consensus that >>>>>> everyone starts submitting patches, and testing, against that one branch. >>>>>> >>>>>> For direct SVN, and git-svn users, this would indeed mean a local change >>>>>> of repository. >>>>>> >>>>>>> >>>>>>>>> SF have posted an update >>>>>>>>> (http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-722/): >>>>>>>> >>>>>>>> Yeah, I saw it. >>>>>>>> >>>>>>>>> - SourceForge Allura Subversion (SVN) service >>>>>>>>> \u2013*offline,*filesystem >>>>>>>>> checks complete, data restoration at 50%. Restoration priority after >>>>>>>>> Git and Hg services. _ETA TBD_, Future update will provide ETA. >>>>>>>> >>>>>>>> Yeah, they don't know when they'll know an ETA. I guess we can forget >>>>>>>> about SVN until next week. >>>>>>>> >>>>>>>> I'll cease all edk2 activity until the SVN repo is back up. This is >>>>>>>> intolerable. >>>>>>> >>>>>>> I agree. When it went offline last week, I couldn't imagine the >>>>>>> downtime would stretch on for a week. >>>>>>> >>>>>>> I hope that anyone trying to push back on switching to from svn to git >>>>>>> can see how dependent the svn centralized model leaves us on a single >>>>>>> server. >>>>>>> >>>>>>> With git, although there would be some hiccups, it would be much more >>>>>>> feasible to setup a temporary alternate upstream location in the event >>>>>>> that the main server goes offline... >>>>>> >>>>>> Right; at least commit hashes would be stable, clones could be updated >>>>>> trivially (by adding a new remote only), and the new patches could be >>>>>> simply pushed back to the original repo from the temporary location once >>>>>> the former came back, without git-format-patch / git-am / >>>>>> git-svn-dcommit. >>>>>> >>>>>> Thanks >>>>>> Laszlo >>>>> _______________________________________________ >>>>> 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
