On 07/19/15 19:48, Ard Biesheuvel wrote: > >> On 19 jul. 2015, at 18:56, Jordan Justen <[email protected]> wrote: >> >>> On 2015-07-19 04:08:50, Laszlo Ersek wrote: >>>> On 07/19/15 12:01, Ard Biesheuvel wrote: >>>>> On 19 July 2015 at 11:50, Laszlo Ersek <[email protected]> wrote: >>>>>> On 07/18/15 20:59, Ard Biesheuvel wrote: >>>>>>> On 18 July 2015 at 20:46, Blibbet <[email protected]> wrote: >>>>>>> I'm getting failures to connect to any of the Tianocore subversion >>>>>>> projects. >>>>>>> >>>>>>> Same issue for the last 2 days. Haven't seen this problem before. I've >>>>>>> tried 2 different systems -- albeit with the same script -- same errors. >>>>>>> >>>>>>> Is Svn working for others, or is this problem somehow isolated to me? >>>>>>> >>>>>>> Has Tianocore moved on to Git-only, and I just missed the memo? >>>>>> >>>>>> No, sadly, sourceforge SVN hosting has indeed been down for 2 days >>>>>> straight. >>>>>> >>>>>> https://twitter.com/sfnet_ops >>>>> >>>>> Looks like SVN restoration will be the last step in their plan: >>>>> >>>>> http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration/ >>>>> >>>>> Looks like SVN might not be back online before mid next week. >>>>> >>>>> Some more links: >>>>> >>>>> http://www.theregister.co.uk/2015/07/17/souceforge_titsup/ >>>>> >>>>> https://www.reddit.com/r/sysadmin/comments/3do9k0/sourceforge_is_down_due_to_storage_problems_no_eta/ >>>>> >>>>> https://www.reddit.com/r/programming/comments/3dm7rk/sourceforge_have_24_hours_down_and_nobody_cares/ >>>> >>>> Sigh. >>>> >>>> I'd suggest that we just promote the GitHub repository to primary >>>> repository, and deprecate the public SVN right away. >> >> I don't think this would be a good idea, unless something even worse >> happens, like sourceforge determined that they can't restore svn. I >> suppose that would really force the issue, but otherwise, I think it'd >> be better to continue with a pre-planned transition. >> > > ok, fair enough. i am not impressed at all by the way SF are handling > this, though, and the projected date to resume full operation seems > fairly coarsly estimated to me.
I certainly don't envy them, and I obviously don't claim that I could give any better estimate in a similar situation. However, I think they could at least give much more frequent updates on <https://twitter.com/sfnet_ops> or <http://sourceforge.net/blog/>. The last update is two days old, and this opacity is simply *maddening*. Someone even mentioned "hour by hour updates": <https://www.reddit.com/r/sysadmin/comments/3do9k0/sourceforge_is_down_due_to_storage_problems_no_eta/ct96y5b>. I wish! The list has been filling up with patches. I'm certainly used to tracking my patches, and patches that I'm supposed to review and/or commit at some point. But, I think with a few more days of this outage, and silence from the ops, we're looking at a lossage of patches, and/or a nice chaotic storm of SVN commits. (Not even mentioning those patches that were already committed but SVN, but didn't make it to the backup, before the live storage crashed.) 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. I'm not sure what the most recent revision in the SVN repo was before SF crashed. The github mirror has r18030. My personal git-svn clone has only r18027. Anyone got anything newer than r18030? Thanks Laszlo > >>>> I am happy to >>>> help out handling any of the fallout that may result, although I >>>> should mention I will be off from work this Tuesday. >>>> >>>> Unfortunately, I don't think the discussion regarding the Git layout >>>> reached any conclusions, so I suppose there may be reasons the >>>> existing SVN users are going to be unhappy with this. So I'd also >>>> suggest that we resume this discussion asap. >>> >>> I've been under the impression that the "general consensus" was to stick >>> with the SVN repo, because >> >> I don't think that is Intel's plan. Instead I think we are trying to >> re-evaluate our git plans based on the community feedback. >> > > ok, i was not aware of that. as laszlo reiterated, svn as-is is > preferable over the proposed git solution, so i am perfectly fine > with sticking to svn in one way or the other until you make up your > minds > > ard. > >>> (a) that would continue to meet Intel's requirement to cherry-pick >>> modules into a build, >>> (b) the git mirror was after all acceptable for most users, >>> (c) git submodules / subtrees, in order to satisfy (a) in a git-only >>> setup, were deemed worse than the current setup. >>> >>> So how about this instead: can Intel migrate the SVN repo to, and >>> maintain it at, 01.org? >>> >>> We've executed an SVN URL change before -- and there are tested ways >>> git-svn can cope with such a change, without cloning from scratch. So >>> the git mirror (and the personal git-svn clones) should survive this. >>> >>> ... Unfortunately, none of the projects listed under Repositories >>> <https://01.org/community?qt-projects_aggregated_links=2> seem to be >>> actually hosted at 01.org... >>> >>> Thanks >>> Laszlo > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
