I queued up the patches you collected: https://github.com/tianocore/edk2-svn-offline/commits/master
Thanks again for collecting them up! -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
