[01:07:26] alright, that couldn't have worked anyway. More ops level stuff to sort out. [01:07:36] and I should go to sleep. [15:32:53] andre__: before I make a faux pas, this is a correct statement, right? [15:32:56] Any data in the new phab-01.wmflabs instance can *and will* disappear. [15:32:59] We make no commitment to transferring any data out of that instance into [15:33:02] the production one. [15:34:23] greg-g, I'm going to quote https://www.mediawiki.org/wiki/Phabricator : [15:34:31] There is a test instance at phab-01.wmflabs.org. Use it to learn and experiment. Don't post relevant content there! Your data might be modified and deleted by others, and the whole instance might just disappear one day. [15:34:58] can we remove the "might" at the end [15:35:29] I want to be explicit "do not count on this, it *will* just be deleted when we have the prod one ready" [15:35:49] well, that instance is meant to be played with. Production is not. [15:35:54] unless we are commiting to transfering the data (which I haven't heard) we need to be explicit. weasel words hurt our ability in the future [15:37:13] greg-g, hmm. gotcha, yeah. It's true that in the year 2038 it will disappear. or so. so you're right. :) [15:37:58] oh, that was unclear to me (and probably others): this instance is meant to stay around for ever? even after the prod instance is ready for work? [15:39:04] we don't have an eg bugzilla-test.wmflabs right now, for instance [15:39:55] I think nobody has really decided yet - I personally see a longer-term potential which is "play with Phab". [15:40:23] meh, we shouldn't be in that business, they can set up their own in labs with the puppet configs fi they want to play [15:40:30] IMHO, bugzilla-test.wmflabs would become "see how imported Bugzilla tickets look like" and rant because you dislike things. [15:40:54] greg-g, in any case, Labs instances are not forever. So you are right and can remove the "might". [15:41:52] ...because "the whole instance will just disappear one day" is an entirely correct statement for any Labs instance. :) [15:42:01] so +1 [15:43:48] and "We make no commitment to transferring any data out of that instance into [15:43:51] the production one." [15:43:54] right? [15:44:05] YES. [15:44:07] greg-g, ^ [15:44:08] coolio [15:44:11] ty sir [15:44:20] there should not be any relevant data in there anyway. says the frontpage [22:06:46] is it normal for the blame links on git.wikimedia.org to choke with a 504 error? [22:06:57] which? [22:07:14] https://git.wikimedia.org/commit/mediawiki%2Fextensions%2FEducationProgram/8117035b899c4914e95a4a91027f4a792a8fa20e [22:07:21] the one there, for example. [22:07:35] that is, this link: https://git.wikimedia.org/blame/mediawiki%2Fextensions%2FEducationProgram/8117035b899c4914e95a4a91027f4a792a8fa20e/EducationProgram.i18n.php [22:09:01] heh, big file [22:09:53] so slow [23:00:36] I got excited that I reached a login screen on the new Phabricator, but then 503 error. [23:10:58] ragesoss: just don't use git.wikimedia.org, it's slow and sucks. [23:13:17] legoktm: I guess that means I have to learn how to use git-blame cli. :/ [23:13:24] oh, use github [23:14:45] oh, our codebase is mirrored to github! :D [23:17:24] oh, github doesn't time out. it just knows it can't handle it, and so won't even let you try. [23:17:39] oh well, found the commit I wanted.