Re: [edk2] TianoCore Subversion down?
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. SF have posted an update (http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-722/): - SourceForge Allura Git service –*offline*, filesystem checks complete, all project data restored, data validation (repository presence check 100%, repository data presence check 100%, ‘git fsck’ of 10% representative from non-empty repositories 100%). Git validation was aided by its feature set. Final data validation pending and_ETA 7/22_ for resumption of service. - SourceForge Allura Mercurial (Hg) service –*offline*, filesystem checks complete, all project data restored. Data validation (repository presence check, repository data presence check, and repository validation to occur and_ETA 7/23_ for service resumption. - SourceForge Allura Subversion (SVN) service –*offline,*filesystem checks complete, data restoration at 50%. Restoration priority after Git and Hg services. _ETA TBD_, Future update will provide ETA. - SourceForge non-Allura SCM platforms and CVS service –*offline,*filesystems checks and data restoration have not commenced. Priority given to modern SCMs which include internal data validation mechanisms; and those repositories fully backed by Apache Allura. Service restoration_ETA TBD_. -- Bruce ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] TianoCore Subversion down?
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. 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... 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 –*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... -Jordan ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] TianoCore Subversion down?
18032 was just a change to maintainers.txt by me replacing Daryl as the maintainer of a few packages with myself. I can send it if necessary, but I'd say it's pretty uninteresting really... -Jaben -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Bruce Cran Sent: Wednesday, July 22, 2015 4:51 AM To: Laszlo Ersek ler...@redhat.com; Ard Biesheuvel ard.biesheu...@linaro.org; Justen, Jordan L jordan.l.jus...@intel.com Cc: Blibbet blib...@gmail.com; edk2-devel@lists.01.org edk2- de...@ml01.01.org; Gao, Liming liming@intel.com Subject: Re: [edk2] TianoCore Subversion down? On 7/22/15 4:18 AM, Laszlo Ersek wrote: My personal git-svn clone has only r18027. Anyone got anything newer than r18030? From https://edk2.bluestop.org/diffusion/EDK/history/ there was also: r18031 MdeModulePkg PiSmmCore: Remove a hidden assumption of SMRAM reservation r18032 Daryl has changed positions and I am taking over maintaining for now. -- Bruce ___ 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] TianoCore Subversion down?
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. 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 –*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. Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] TianoCore Subversion down?
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 –*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
