[12:02] <spiv> ddaa: meeting time?
[12:03] <ddaa> spiv: yes
[12:03] <mpool> here?
[12:03] <ddaa> SteveA: ping
[12:03] <spiv> BazaarMeetingAgenda says here.
[12:03] <ddaa> lifeless: ping
[12:03] <lifeless> gnip
[12:04] <SteveA> hi
[12:04] <ddaa> jamesh should arrive soon
[12:04] <ddaa> Meeting starts
[12:04] <ddaa> Agenda
[12:04] <ddaa>  * roll call
[12:04] <ddaa>  * production status
[12:04] <ddaa>  * Smart server
[12:04] <ddaa>  * SFTP advertising
[12:04] <ddaa>  * vcs-import knits
[12:04] <ddaa>  * supermirror branch browser
[12:04] <ddaa>  * private branches
[12:04] <ddaa>  * dyson
[12:04] <ddaa>  * empty hosted branches
[12:04] <ddaa>  * Python import
[12:04] <ddaa>  * critical bugs
[12:04] <ddaa>  * pending sysadmin tasks
[12:04] <ddaa>  * any other business?
[12:04] <ddaa> -----
[12:05] <ddaa> * Roll call
[12:05] <ddaa> I'm obviously here
[12:05] <mpool> here
[12:05] <ddaa> and all participants too, I see
[12:05] <ddaa>  * Production status
[12:05] <ddaa> Nothing new.
[12:05] <ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/53825
[12:05] <ddaa> Still spamming launchpad-error-reports. No short term fix expected.
[12:05] <ddaa> What was the output of the launchpad-infra meeting about oops-from-scripts?
[12:05] <lifeless> jamesh: ?
[12:05] <jamesh> lifeless: yeah?
[12:05] <lifeless> ^^ do you know :)
[12:06] <jamesh> ddaa: we haven't discussed it yet
[12:06] <ddaa> Okay, happy to leave it that way, eventually kiko will grow tired of the spam, but we are not there yet.
[12:06] <jamesh> I'll be discussing some oops stuff with matsubara today, but I don't know if we'll get to oops-from-scripts
[12:07] <ddaa>  * Smart server
[12:07] <ddaa> mpool, spiv: report?
[12:07] <mpool> no substantial progress this week
[12:07] <ddaa> did not ask last week
[12:08] <mpool> spiv, we should meet this week to pair on it, then i'd like you to do more, if possible
[12:08] <spiv> mpool: tomorrow?
[12:08] <lifeless> works for me
[12:08] <mpool> ddaa: the status is that it's still trying to get all branch/repo tests to pass
[12:08] <mpool> tomorrow is ok with me
[12:08] <ddaa> Okay, I'll ask again next week.
[12:09] <ddaa>  * SFTP advertising
[12:09] <ddaa> jamesh posted draft on launchpad@, I commented, and expect a second draft.
[12:09] <ddaa> I would like some feedback from the other guys (mpool, lifeless, spiv) if you have the time. Anybody wants to make a commitment?
[12:09] <jamesh> I'll post a second draft once I've addressed the problems ddaa mentioned
[12:09] <lifeless> no committment, sorry.I've followed the email discussion and it sounds like it will be good
[12:10] <ddaa> mpool: spiv: ?
[12:10] <spiv> I'm happy to read over the second draft.  I didn't pay close attention to the first one as I was trying to get through the flood of mail that built up during my week of leave :)
[12:11] <ddaa>  * vcs-imports knits
[12:11] <ddaa> Scream if you want that done this month, as I have enough things to keep me busy until leave (17th to 25th this month).
[12:11] <mpool> draft looked reasonable
[12:12] <mpool> ddaa: what are you working on til then?
[12:12] <lifeless> It would be nice to do it this month. Depending.
[12:12] <ddaa> mpool: I'll tell later, it's on the agenda :)
[12:12] <ddaa> Okay, talk again about it at the end of the meeting.
[12:12] <lifeless> I think weave branches are now into bad publicity area. 
[12:12] <lifeless> right, later
[12:13] <ddaa>  * Supermirror branch browser
[12:13] <ddaa> spiv: what's your delivery estimate? (you promised one a couple of weeks ago).
[12:13] <ddaa> spiv: you look a bit overloaded with bzr stuff...
[12:14] <spiv> ddaa: Yeah, I've been switching to focusing heavily on smart server for that moment, so I don't intend to work on the branch browser until that's done.
[12:14] <ddaa> Okay, if nobody disagrees, I'll drop the branch browser from the agenda until further notice.
[12:15] <ddaa> Apparently, nobody disagrees.
[12:15] <ddaa>  * Private branches
[12:15] <ddaa> lifeless to reply to review comments. Unless somebody disagree, I'll drop that from the agenda.
[12:15] <lifeless> fine
[12:15] <ddaa>  * Dyson
[12:15] <ddaa> Progress on that appears stalled. Unless somebody disagree, I'll drop that from the agenda.
[12:15] <lifeless> please keep it
[12:16] <lifeless> jamesh: that is currently with you AIUI
[12:16] <ddaa> Okay. Will keep nagging people about Dyson.
[12:16] <lifeless> jamesh: is that your understanding?
[12:16] <SteveA> The branch browser is important to me for dealing with bad "trivial" landings on launchpad development.
[12:16] <ddaa> mh?
[12:17] <SteveA> If spiv can't do it over the next 2 weeks, I'd like to get someone else to do it
[12:17] <jamesh> lifeless: I got the input from Mark and Scott about it
[12:17] <spiv> SteveA: The task of setting it up internally is considerably smaller than the larger task.
[12:17] <lifeless> SteveA: we can deploy a branch browser for launchpad separately
[12:17] <ddaa> SteveA: isn't that something requiring private branches first?
[12:17] <jamesh> lifeless: I'm not exactly sure how we want to proceed
[12:17] <lifeless> SteveA: thats trivial
[12:17] <spiv> ddaa: not involving launchpad at all.
[12:17] <lifeless> jamesh: ok, after this meeting, lets talk in #launchpad and get you unblocked.
[12:18] <jamesh> lifeless: I probably won't have time to work on it this week either way.
[12:18] <lifeless> SteveA: I'm completley happy for you to get someone else to do the lp browser instance. If you have someone who can do one for the supermirror too, that would be great.
[12:18] <SteveA> if it is trivial, can ew get it done this week?
[12:18] <ddaa> spiv: SteveA: okay but that meeting item was about the launchpad branch browser. Having a non-launchpad one for rocketfuel is an infra-team thing AIUI.
[12:19] <SteveA> ok
[12:19] <SteveA> ddaa: "Dyson"
[12:19] <SteveA> I forget what that is again
[12:19] <lifeless> SteveA: I will get a core instance up and running and email rt for admin foo, after that its up to you
[12:19] <lifeless> SteveA: upstream release tarball scanner
[12:19] <SteveA> I asked last meeting for more descriptive names for "Dyson" and "Roomba"
[12:19] <SteveA> and mpool seconded
[12:19] <ddaa> SteveA: creating product releases automatically off tarballs found on the internet.
[12:20] <spiv> ddaa: Well, having the internal one was a stepping stone to the larger one.
[12:20] <lifeless> yes, dyson was scotts invention. roomba as mine
[12:20] <ddaa> roomba -> soon-eradicated-importd-autotester
[12:20] <lifeless> spiv: overengineering IMO. one sec
[12:20] <SteveA> jamesh has offered to do the launchpad browser
[12:20] <SteveA> that issue is closed now, thanks
[12:21] <ddaa> dyson -> tarball-spider ?
[12:21] <SteveA> importd-autotester adn tarball-spider
[12:21] <SteveA> fine
[12:21] <ddaa> Moving on.
[12:22] <ddaa>  * Empty hosted branches
[12:22] <ddaa> It occured to me that fixing https://launchpad.net/products/bzr/+bug/30576 (bzr push to an extant non-branch directory fails horribly)
[12:22] <ddaa> was only half of the fix. The other half would be fixing 
[12:22] <ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/51130 (cannot use +admin on a branch I own)
[12:22] <ddaa> and https://launchpad.net/products/launchpad-bazaar/+bug/34540 (cannot delete a branch),
[12:22] <ddaa> I plan to fix 51130 before leave.
[12:22] <ddaa> That said, I'll drop this item from the agenda.
[12:22] <ddaa>  * Python import
[12:22] <ddaa> bad news
[12:23] <ddaa> Keeps failing in mid-course with a pysvn._pysvn.ClientError on PROPFIND "Could not resolve hostname `svn.python.org': Host not found (http://svn.python.org)".
[12:23] <ddaa> It's not clear what's the cause of the problem, but I guess fixing it would involve:
[12:23] <ddaa> - either import from svn dump (in importd)
[12:23] <ddaa> - or replacing uses of pysvn by python-subversion in the critical sections (in cscvs), I expect that would give us better control on network usage.
[12:23] <ddaa> I would like to have this sort of change done _after_ removing Arch support from the corresponding component.
[12:23] <ddaa> In other words, we're not going to have it this month unless it's made a top priority.
[12:24] <mpool> i'd be a bit unhappy to have it deferred so long
[12:24] <ddaa> In still other words, our svn import stuff sucks badly.
[12:24] <mpool> i think you should consider it a key test case
[12:24] <ddaa> *sigh* test case fails, cscvs is not robust, old news
[12:25] <ddaa> Though, fixing that in importd could be done without having to deal with Arch
[12:25] <mpool> lifeless: what's your opinion?
[12:26] <lifeless> work on concrete user visible goals
[12:26] <lifeless> if there is interest in python in bzr-svn copy, then work on making it work
[12:26] <ddaa> since that would be part of the "set up source tree for cscvs" code, which is target-independent
[12:27] <lifeless> I think diagnosing the cause is important too
[12:27] <lifeless> python-subversion was a PITA to work with 18 months ago
[12:27] <lifeless> if it has improved, great.
[12:28] <mpool> ddaa: so it always failes with "host not found"? 
[12:28] <mpool> how odd
[12:28] <ddaa> at random points in the conversion
[12:28] <mpool> ok, we should take this to mail...
[12:28] <ddaa> not at the start
[12:28] <ddaa> want me to write email about it?
[12:29] <ddaa> okay, will do
[12:29] <ddaa>  * Critical bugs
[12:29] <ddaa> No concrete change.
[12:29] <ddaa> - Cannot set branch associated to a product series. https://launchpad.net/products/launchpad-bazaar/+bug/31308
[12:29] <ddaa> lifeless to write spec
[12:29] <ddaa> - renaming project, product or series breaks vcs imports. https://launchpad.net/products/launchpad-bazaar/+bug/37897
[12:29] <ddaa> Have design and done preimpl call. My current top priority. Still expecting lifeless to brain dump about uploading/downloading cscvs source trees on remote servers.
[12:29] <ddaa> - cannot use +admin on a branch I own. https://launchpad.net/products/launchpad-bazaar/+bug/51130
[12:29] <ddaa> I plan to fix that before leave as part of ongoing plan to have fun improving user-visible stuff.
[12:30] <ddaa> mpool: that answers your earlier question about my current coding focus
[12:30] <ddaa> lifeless: please give me that braindump, I value your input on that design.
[12:30] <lifeless> ok
[12:30] <mpool> ddaa: ok
[12:31] <mpool> (can i retitle that? bug 51130)
[12:31] <ddaa> yeah, the title has gone wrong
[12:31] <mpool> done
[12:31] <ddaa> the expected fix is to delete +admin and move its contents to +edit
[12:31] <ddaa> unless I change my mind
[12:32] <lifeless> SteveA: browser is up and running
[12:32] <ddaa> * Pending sysadmin tasks
[12:32] <ddaa> * Any other business?
[12:32] <SteveA> lifeless: cool!  URL please
[12:32] <lifeless> on sodium, http://localhost:8088/ 
[12:33] <SteveA> so, RT needed to expose externally
[12:33] <lifeless> this is a minimal config, we can add multiple branches, etc in the future.
[12:33] <spiv> lifeless: can't you run it as a cgi out of your homedir?
[12:33] <lifeless> I'd like you to RT it
[12:33] <lifeless> spiv: use case - trivial - done. fancy-pants-high-performance can wait for the supermirror code alterations
[12:33] <mpool> just to check something from before - jamesh will be working on the branch viewer?
[12:34] <ddaa> * vcs-imports knits, should that be set as a top priority for that month?
[12:34] <spiv> lifeless: running as a cgi is hardly a performance booster ;)  But ok.
[12:34] <jamesh> was going to work on the one for launchpad's branches (which lifeless seems to have up and running).  Not sure about the supermirror one
[12:34] <lifeless> SteveA: I'd like you to RT it please, choose where you would like it to exposed etc. I've put it up immediately because that fulfils your requirements immediately.
[12:34] <SteveA> lifeless: sure.  i'll do that. ta
[12:34] <lifeless> np
[12:35] <lifeless> we aim to please
[12:35] <lifeless> its running as the PQM user. at this point if sodium is rebooted it will go away.
[12:35] <lifeless> we can refactor the implementation later to be better as needed.
[12:35] <jamesh> lifeless: so that's just the main rocketfuel branch.  I think we want other branches too (I suppose that can be done later)
[12:35] <ddaa> jamesh: looks like the one for rocketfuel was grabbed by lifeless :)
[12:36] <lifeless> well, I did mean it was trivial.
[12:36] <ddaa> Focus, please.
[12:36] <lifeless> SteveA: please file bugs on the launchpad-development-infrastructure product with things you want changed in the browser - branches to show etc.
[12:36] <ddaa> So, SteveA request was granted, take deployment details on after meeting.
[12:37] <lifeless> knits - IMO its a priority
[12:37] <ddaa> Is that more important than fixing 51130?
[12:37] <mpool> converting existing weave branches to knits?
[12:38] <mpool> why is it difficult?
[12:38] <lifeless> theres 500 to do
[12:38] <lifeless> each has to be done in two places
[12:38] <ddaa> some of them stupidly large
[12:38] <ddaa> do not want to do that manually
[12:38] <ddaa> so need to be implemented as transition automation in importd
[12:39] <ddaa> so, not difficult per see, just a significant coding task
[12:40] <ddaa> Waiting for opinion on whether I should drop one of my current tasks for that, or on somebody to provide extra workforce.
[12:41] <lifeless> I'd like to get it done and out of the way
[12:42] <lifeless> mpool: your thoughts?
[12:42] <mpool> well, i can't judge how much work it woul dbe
[12:43] <mpool> i mean, even if there are many of them surely it should be just a couple dozen lines of shell at most?
[12:43] <ddaa> mpool: we do not want shell
[12:43] <mpool> but i would not want someone actually using the weave branches - they will be awfully slow over http
[12:43] <ddaa> we want that in importd because it's a shared resource issue and format upgrade is a recurrent task
[12:43] <lifeless> mpool: unless you shut down the entire system while you do it you need to lock/unlock the branch being converted at the scheduler level
[12:44] <lifeless> mpool: you also need urls from launchpad
[12:44] <ddaa> and doing that sort of thing in shell is a LARGE pita because it needs to be distributed on many systems.
[12:45] <mpool> i'm not actually suggesting shell, just saying that what actually runs is conceptually small
[12:45] <mpool> so i wonder if there is any lazier way to do it?
[12:45] <ddaa> BTW, fixing 51130 would make it easy to temporarily shut down importd-autotest with importd-production so we get maximal horsepower for the conversion.
[12:45] <mpool> e.g. i'd rather shut down imports for 24-48 hours than have david spend a week writing this
[12:45] <ddaa> s/shut down/merge
[12:46] <ddaa> mpool: who do you think would spend 48 setting up, testing, and babysitting the upgrade hack?
[12:46] <lifeless> see I dont understand why its more than 2 lines of python
[12:47] <lifeless> but thats a different discussion. lets have that post meeting
[12:47] <lifeless> mpool: lets talk priorities now, not costs
[12:47] <ddaa> does the spec I wrote look like more than two lines of python?
[12:47] <lifeless> lets talk after the meeting
[12:47] <ddaa> Okay, so issue still open.
[12:47] <lifeless> the discussion right now should be priorities IMO
[12:48] <mpool> ok, so
[12:48] <ddaa> And meeting time is over.
[12:48] <lifeless> mpool: I think eliminating weaves is importnt
[12:48] <mpool> after the meeting, dda, robert, mbp to talk about ddaa's suffering
[12:48] <ddaa> ta, it's not whining, it's good use of programmer's time
[12:49] <ddaa> Meeting over
[12:50] <ddaa> I'm out for a small break.
[12:51] <mpool> back in 10 say?
[01:02] <ddaa> mpool: I'm back
[01:04] <mpool> back
[01:04] <ddaa> https://launchpad.canonical.com/VcsImportsKnitsUpgrade
[01:06] <ddaa> There appears to be a single import in STOPPED mode, and I'm not sure it should not be syncing instead
[01:07] <ddaa> so we can drop the provisions for STOPPED in that spec
[01:07] <mpool> what does that mean?
[01:07] <mpool> i mean, what does "stopped" mean?
[01:07] <ddaa> it means "was once in sync, is published, but is no longer updated"
[01:08] <ddaa> mainly so we do not get distracted by errors of things that we know will fail for reasons we cannot fix (like the repository went away)
[01:09] <ddaa> that comes from there https://launchpad.canonical.com/SourceSourceRefactoring
[01:09] <ddaa> look at the bottom of the page
[01:10] <ddaa> also look for ImportStatus in canonical/lp/dbschema.py
[01:10] <mpool> i see
[01:11] <mpool> and the public server pulls from the internal http server
[01:11] <ddaa> yes
[01:11] <mpool> but if the branch already exists on the public server, how will the upgrade propagate?
[01:11] <mpool> pull does not do an upgrade
[01:11] <mpool> iirc
[01:11] <ddaa> https://launchpad.canonical.com/VcsImportsKnitsUpgrade
[01:12] <lifeless> I will comment, but I have to finish a meeting first
[01:12] <mpool> oh i see, right
[01:12] <mpool> it's not doing a regular pull
[01:12] <ddaa> if an upgrade is needed, importd will 1. pull 2. upgrade locally 3. recursive delete remote branch 4. push before running cscvs
[01:12] <mpool> "
[01:12] <mpool> The branch-puller preserves changes in branch format, so format changes on the vcs-imports internal publication server will be propagated to  http://bazaar.launchpad.net."
[01:12] <ddaa> mpool: that issue has been addressed already
[01:12] <mpool> right but how does the branch-puller do that?
[01:13] <ddaa> if the branch puller sees that the source and the target have different formats (in any way), it will delete the target and do a branch from scratch.
[01:13] <mpool> ok
[01:14] <mpool> so the branch will just disappear from b.lp.n until the upgrade is pulled across?
[01:14] <mpool> i guess that's ok
[01:14] <ddaa> yes
[01:14] <ddaa> maybe there's some special provision to reduce the window of loss of service, but it's not really important
[01:15] <spiv> After all, one of the nice things about distributed version control is that temporary outages aren't totally disruptive.
[01:15] <ddaa> so, it might very well be that the required changes to importd are small
[01:16] <ddaa> but I'm not fluent in bzrlib
[01:16] <ddaa> and there tends to be annoying integration issues in importd
[01:16] <ddaa> so it's not a low risk task
[01:16] <ddaa> I'd say medium risk
[01:16] <mpool> i don't think the interruption is a big deal, i just wondered
[01:17] <mpool> one other question: presumably all of this is backed up?
[01:17] <ddaa> There's also the fact that the conversion is expected to be a big deal processing wise
[01:17] <mpool> so if something goes wrong and it starts deleting branches...
[01:17] <mpool> ?
[01:17] <ddaa> mh...
[01:17] <ddaa> dunno, I expect it is backed up... but access to the repositories are quite restricted
[01:18] <ddaa> and it's a bit hard to go _that_ wrong
[01:18] <ddaa> so, big deal processing wisu
[01:18] <ddaa> definitely not something you want to run on a single system
[01:18] <mpool> i think it'd be sensible to check before starting
[01:18] <mpool> the spec looks reasonable to me
[01:19] <ddaa> I do end-to-end tests with the whole system on my workstation before deployinh disruptive code like that
[01:19] <ddaa> There's usually a minor tweak or two needed when deploying things, but there was never a major disaster.
[01:20] <mpool> cool
[01:20] <ddaa> So, you want multiple systems running the stuff
[01:20] <ddaa> that turns a small one-off hack into a relatively large mess
[01:21] <ddaa> and format conversion is not one-off
[01:21] <ddaa> it's going to happen again in the future
[01:21] <mpool> yeah, it makes sense
[01:21] <mpool> so, essentially we are trying to prioritise the upgrade spec against
[01:21] <mpool> - unjamming the python import
[01:21] <mpool> - cleanups of arch code
[01:22] <mpool> what else?
[01:22] <ddaa> - critical fixes I'm working on now
[01:22] <mpool> ok
[01:23] <ddaa> I particular, I think it makes sense to do the upgrade thing after fixing https://launchpad.net/products/launchpad-bazaar/+bug/37897
[01:23] <mpool> so it looks like the upgrade mechanism is largely independent of other things - e.g. removing arch dependencies won't make it much easier, or vice versa?
[01:23] <ddaa> because that will allow use to handle the load by putting all four importd systems (including the ones currently running autotest) temporarily in importd-production
[01:24] <ddaa> I'm happy to proritise that before arch cleanups.
[01:24] <ddaa> since it can be put into the bzr-specific code that gets the target branch
[01:25] <ddaa> might not be the optimal way to organise the code, but that would avoid messing up the pattern of arch/bzr testing
[01:26] <mpool> ok
[01:26] <mpool> well, let's see what robert says
[01:27] <ddaa> lifeless can give support to the relevent requests
[01:29] <ddaa> And it's something I'll need eventually, since I want to remove the need for importd-autotest altoghether (we can now to that since we no longer have to deal with arch namespace issues)
[01:29] <lifeless> ok
[01:30] <lifeless> I'm back
[01:30] <lifeless> where are we up tp?
[01:31] <ddaa> need your input or prioritizing knits upgrade
[01:32] <lifeless> ok
[01:32] <lifeless> so I was going to ask
[01:32] <lifeless> isn't the upgrade as simple as invoking bzr upgrade via python *always* on every branch ?
[01:33] <lifeless> invoke it on both the local branch and the remote one, before pulling etc etc
[01:33] <ddaa> hu
[01:33] <ddaa> remote upgrade?
[01:33] <ddaa> it's on LAN, but still...
[01:34] <ddaa> if we put it down to that, it will be indeed just a couple of lines of code
[01:35] <ddaa> since we currently download the branch anew for every sync
[01:35] <ddaa> but really do not like the idea
[01:36] <ddaa> for example, how will "bzr upgrade" behave if the first upgrade is interrupted (process killed, loss of connection), and we try to run a second one?
[01:37] <ddaa> BTW, need to make a bug importd not breaking sftp locks
[01:37] <ddaa> it should be able to do that
[01:38] <lifeless> bzr upgrade takes a backup copy of data. It marks the branch as being in-upgrade
[01:38] <lifeless> so it will need manual recovery- but this is IMO better than the failure mode of the upgrade you proposed
[01:39] <lifeless> where it will have no data remotely, and no data locally (because it will be trying to pull anew)
[01:39] <ddaa> gn?
[01:39] <ddaa> remote data would only be deleted after a successful local upgrade
[01:39] <ddaa> oh right
[01:39] <lifeless> if we download the branch anew each time, my suggestion is just 'invoked bzr upgrade on the remote branch before pulling it'
[01:40] <lifeless> which should be trivial to implement, and result in automatic upgrades as we change the defaults
[01:40] <ddaa> What does importd need to do to recover from an interrupted upgrade?
[01:41] <lifeless> well, there are two failure types
[01:41] <lifeless> a) bzr bugs
[01:41] <lifeless> b) network glitch
[01:41] <ddaa> c) kernel upgrade
[01:41] <lifeless> for b), its - rm -rf the .bzr dir, and move .bzr.backup to .bzr
[01:41] <lifeless> c) counts as b)
[01:41] <ddaa> anh other variants of c, like importd upgrade
[01:41] <ddaa> yeah
[01:42] <lifeless> for a), you need to diagnose it and work with the bzr devs to get the upgrade to work
[01:42] <ddaa> how can you automatically detect b?
[01:42] <lifeless> IMO you should treat them all as a), because theres no magic way to tell what caused the failure
[01:43] <ddaa> you realise that "needs manual diagnostic" for import pretty much means "will not be fixed"
[01:43] <lifeless> is jamesh's log analysis stuff rolled out for importd ?
[01:43] <ddaa> I ran it once
[01:43] <lifeless> if so, then this should be marked clearly in that report
[01:44] <ddaa> but not again, because there were just too many failures to deal with
[01:44] <lifeless> and as any bug in this stuff is of critical importance to bzr, I dont agree that needs manual diagnostic means 'will not be fixed' 
[01:44] <ddaa> and there was no easy way to classify them
[01:45] <mpool> ok, well
[01:45] <mpool> i'd like to call it a night...
[01:45] <lifeless> jamesh: is there something that could be easily done to make flagging failed upgrades stand out hugely in your log analyser for importd ?
[01:45] <lifeless> mpool: what time for spiv and I tomorrow ?
[01:46] <mpool> presume you're coming here?
[01:46] <mpool> after 10?
[01:46] <lifeless> I presume that too
[01:46] <lifeless> k
[01:46] <lifeless> spiv: ^?
[01:46] <ddaa> lifeless: does bzrlib gives a specific exception when trying to upgrade a branch that failed upgrade already (and is thus marked upgrade-in-progress)?
[01:46] <lifeless> ddaa: yes 
[01:47] <ddaa> okay, that should be easy to grep for
[01:47] <lifeless> ddaa: UnknownFormat
[01:47] <mpool> what effect does an ascii del have on a spiv? i hope it doesn't kill him :-)
[01:47] <lifeless> ddaa: or ~ that - check bzrlib/errors.py ;)
[01:47] <lifeless> ddaa: ok, does this sound like a workable plan then ?
[01:48] <ddaa> Sounds workable.
[01:48] <ddaa> Then _when_ ?
[01:48] <lifeless> ok, cool.
[01:48] <lifeless> yesterday :)
[01:48] <ddaa> ASAP, or when we can put all our cpus on it?
[01:48] <lifeless> IMO ASAP. upgrade will chew through over a couple of days
[01:49] <lifeless> no need for massive parallisation
[01:49] <lifeless> it wont block all imports indefinately, because each import will block just long enough to upgrade, then do a pull from CVS
[01:49] <ddaa> yeah
[01:50] <lifeless> ok, gnight then
[01:50] <ddaa> once we get in the tail of the exponential distribution, (the 5 biggest branches), the other imports should be allowed to sync again
[01:51] <ddaa> lifeless: BTW
[01:51] <ddaa> jamesh appears to busy to review my last importd-bzr-native
[01:51] <lifeless> ddaa: not the case
[01:51] <ddaa> okay
[01:52] <lifeless> ddaa: was discussed in the review meeting, see irc logs or lp-reviews
[01:52] <lifeless> gnight
[01:52] <ddaa> nigh
[01:52] <ddaa> night
[02:14] <spiv> mpool, lifeless: soon after 10 sounds good to me.