[00:32]  * thumper attempts to suspend again
[00:33] <lifeless> sinzui: I'm going to work on the moderate thing
[00:34] <thumper> yay, it worked
[00:37] <lifeless> thumper: ping
[00:37] <thumper> lifeless: hey
[00:37] <lifeless> https://bugs.edge.launchpad.net/launchpad-code/+bug/633758 - can has qa?
[00:38]  * thumper gets on it
[00:38] <lifeless> (oh, and goo dmorning)
[00:39] <thumper> morning
[00:39] <thumper> my talk went well I think
[00:41] <lifeless> thumper: cool
[00:41] <lifeless> what was it ?
[00:41] <thumper> qa done
[00:41] <thumper> I was giving a talk to second year software engineering students about our development process
[00:42] <lifeless> one of the errors last night on BB : bzrlib.errors.InvalidHttpResponse: Invalid http response for https://xmlrpc.edge.launchpad.net/bazaar/: Unable to handle http code 502: Bad Gateway
[00:42] <thumper> a one hour lecture
[00:42] <thumper> ?!?
[00:42] <lifeless> thumper: 'we throw stuff at the wall and hope it works'
[00:42] <lifeless> thumper: the 502 is probably an edge deploy.
[00:42] <lifeless> thumper: I wonder what bzr version it is, that its using edge
[00:44]  * lifeless waits for https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt to update
[00:57] <lifeless> sinzui: is there a list with lots of messags that I can look at the moderation page with ?
[01:11] <lifeless> Edwin-afk: / jcsackett: https://bugs.edge.launchpad.net/launchpad-registry/+bug/597738 needs QA for the latest landing (rev 11547)
[02:08] <lifeless> thumper: https://code.edge.launchpad.net/~lifeless/launchpad/cp/+merge/35764
[02:08] <lifeless> thumper: No new code, and I've marked up all the user facing / risk mitigating/correcting changes.
[02:08] <lifeless> thumper: I'd like to get this through ec2 today to ask for a CP on monday.
[04:46] <lifeless> thumper: ping?
[04:47] <thumper> lifeless: hey
[04:47] <lifeless> could you tag your review release-critical please?
[04:47] <lifeless> (thanks for doing it)
[04:49] <wgrant> When's the next release?
[04:49] <thumper> lifeless: so this is part of the "try to release more often?"
[04:50] <thumper> just trying to work out your rationale
[04:54] <thumper> lifeless: my thinking is based around marking it "release-critical" where it clearly isn't just to cross some 'T's and dot some 'I's seems stupid
[04:55] <thumper> if we are changing the process, we should just do it
[04:55] <thumper> and not require this fake stamp just for the hell of it
[04:59] <lifeless> thumper: yes
[04:59] <lifeless> thumper: I suggest; we do this under the current process, and simultaneously point out that the current process is more onerous than the proposed, approved RFWTAD process
[05:00] <lifeless> thumper: and so qa-ok'd stuff gets a free pass for CP's.
[05:00] <lifeless> thumper: we'll need to tweak some toolchain stuff though - at least for the moment we *need* release-critical stamps to get past PQM.
[05:00] <lifeless> and PQM isn't really setup to check 'has been qa-oked'.
[05:00] <lifeless> wgrant: three weeks
[05:00]  * thumper sighs
[05:01] <thumper> lifeless: so you need the rc to get pqm to land it?
[05:01] <lifeless> wgrant: yes
[05:01] <lifeless> bah
[05:01] <lifeless> thumper: yes
[05:01] <wgrant> Hm.
[05:01] <thumper> ok, I'll stamp it
[05:02] <wgrant> There are revs in devel that shouldn't go out onto prod, AFAICT...
[05:02] <lifeless> wgrant: yes, my branch isn't all of devel
[05:02] <lifeless> wgrant: its all the ones passed by the qatagger
[05:02] <wgrant> eg. r11552 enabled some unfinished UI on prod.
[05:02] <wgrant> The bug doesn't have a tag, so I don't know its QA status.
[05:02] <lifeless> wgrant: I'm doing up to and including 11546
[05:03] <lifeless> thats all that has been fully QA'd.
[05:03] <wgrant> Aha.
[05:03] <wgrant> Everything up to there is fairly sane, IIRC. Sounds good.
[05:06] <wallyworld> thumper: ping?
[05:06] <thumper> wallyworld: aye
[05:06] <wallyworld> just want to check something....
[05:07] <wallyworld> anyone can submit a merge proposal, right?
[05:07] <thumper> wallyworld: as long as they can see the source and target branches, yes
[05:08] <wallyworld> ok. there's some ambiguity with some of the comments in a test
[05:08] <wallyworld> just wanted to confirm, thanks
[05:08] <wallyworld> i might skype you later if i need to discuss
[05:19] <jtv> StevenK: did you ever figure out that broken test?
[05:23] <StevenK> jtv: Which one?
[05:24] <jtv> StevenK: the one you suspected fakelibrarian of
[05:24] <StevenK> jtv: I didn't investigate it, sorry
[05:25] <jtv> StevenK: Oh, I thought it was what put db-devel into testfix so I thought it'd be a big thing.
[05:32] <jtv> lifeless: are you familiar with LaunchpadScriptLayer?
[05:33] <lifeless> No, but i can be
[05:33] <lifeless> why?
[05:33] <jtv> It combines ZopelessLayer and LaunchpadLayer, and adds one thing:
[05:33] <jtv>         provideUtility(TestMailBox(), IMailBox)
[05:34] <jtv> There's a 4-year-old XXX from Francis saying it should be registered via ZCML in LaunchpadFunctionalLayer.
[05:35] <jtv> Sorry; the comment says it _is_ registered via ZCML in the LaunchpadFunctionalLayer.
[05:35] <jtv> Anyway, this smells of installFixture to me.
[05:36] <jtv> I was thinking tests that use this could use ZopelessDatabaseLayer instead, and install fixtures for the test mailbox and if needed, the fake librarian.
[05:40] <jtv> (Or if they need the real librarian, they could use LaunchpadLayer—though that provides memcached which I'm not sure scripts are currently supposed to access)
[05:41] <lifeless> so
[05:41] <lifeless> I'd like to move all our 'layers' to use fixtures, decoupling stuff
[05:41] <lifeless> specifically
[05:41] <lifeless> lp:python-fixtures
[05:41] <lifeless> I need to tweak the API a little more though
[05:47] <lifeless> jtv: 16:41 < lifeless> so
[05:47] <lifeless> 16:41 < lifeless> I'd like to move all our 'layers' to use fixtures, decoupling stuff
[05:47] <lifeless> 16:41 < lifeless> specifically
[05:47] <lifeless> 16:41 < lifeless> lp:python-fixtures
[05:49] <jtv> lifeless: thanks for repeating—my IRC connections are extra-weird today.  Yes, fixtures instead of layers would be good.  I've gotten used to reserving setUp for that sort of thing—as opposed to the creation of repetitive test data.
[05:49] <poolie> hello jtv!
[05:49] <jtv> hi poolie!
[05:49] <jtv> How's things?
[05:50] <poolie> good; i thought my drive had died but it was just a loose cable
[05:50] <poolie> though it's a bit annoying to lose time to carefully working this out
[05:50] <jtv> Life's little rollercoasters
[05:50] <jtv> I'm _hoping_ I've got a similar problem with my backup drive. :)
[05:51] <poolie> how do i provoke an oops again?
[05:51] <lifeless> poolie: do something wrong
[05:51] <lifeless> poolie: :P
[05:51] <lifeless> poolie: ++oops++
[05:52] <poolie> ah, and it appears in the comment
[05:52] <poolie> thanks!
[05:52] <poolie> and i see the memcache feature was used! yay
[05:52] <lifeless> poolie: it was ?
[05:52] <lifeless> oh yes, it will get evaluated
[05:52] <poolie> according to the comment in view-source:https://edge.launchpad.net/bzr/ it was queried
[05:52] <poolie> i don't know if it had any effect
[06:00] <lifeless> yes, any page that uses memcache will query it
[06:15] <lifeless> back later
[08:25] <henninge> jtv: I have converted the import code but still some tests are failing.
[08:25] <jtv> henninge: what problems are you hitting?
[08:26] <henninge> jtv: let me have a closer look, 'll get back to you in a few minutes.
[08:31] <henninge> jtv: http://paste.ubuntu.com/495141/
[08:31] <henninge> jtv: I have not yet worked with Karma.
[08:31] <henninge> jtv: Is that something updateTranslation does, too, which I need to do manually now?
[08:32] <jtv> henninge: shall I run you through the conceptual model of karma?
[08:32] <jtv> What's happening here is that the karma we assign has changed a bit
[08:32] <henninge> jtv: that would be nice
[08:33] <jtv> In a nutshell, karma can be assigned in various contexts (somewhat similar to our queue entries, really).
[08:33] <henninge> (only 5 failing tests in lp.translations, btw)
[08:33] <jtv> Additionally, each assignment of karma is in a particular category.
[08:34] <jtv> In the database, you might thus have a karma record that says something like "henning earned 5 karma points today in category marking-a-bug-as-fix-released, for the gim."
[08:34] <jtv> updateTranslation assigns karma.
[08:34] <jtv> It does so in Mysterious Ways.
[08:35] <henninge> ;-)
[08:35] <jtv> I did not try to reconstruct and emulate exactly how, when & what.
[08:35] <henninge> but it is still done by ... sumitSuggestion/approve/... ?
[08:35] <jtv> Instead, we now have a model that's relatively easy to track (see POTMsgSet, though I added an implementation method to POTemplate)
[08:35] <jtv> Yes.
[08:36] <jtv> Well, not "still" since those messages are new.  :)
[08:36] <jtv> *methods
[08:36] <henninge> yes, but they are the replacements for updateTranslation
[08:36] <jtv> Off the top of my head, we award 3 kinds of karma:
[08:36] <jtv>  * Submitting a suggestion.
[08:36] <jtv>  * Reviewing.
[08:36] <jtv>  * Having your suggestion approved by someone else.
[08:37] <henninge> jtv: ok, I see two of those in the traceback
[08:37] <jtv> Those are now neatly separated, with rules like "don't assign review/approved karma for someone approving their own translations."
[08:37] <henninge> where are they defined?
[08:37] <jtv> Look for awardKarma in potmsgset.py
[08:38] <jtv> One in submitSuggestion, and two in approveSuggestion.
[08:38] <jtv> Come to think of it, I think I forgot to do that in approveAsDiverged!
[08:39] <jtv> And clearCurrentTranslation.  That's review karma for the reviewer, I think (assuming that there really are suggestions).
[08:41] <henninge> ok
[08:42] <henninge> maybe I need to add that. I use approveAsDiverged in the import if the incumbent ;) message was diverged.
[08:44] <jtv> Then that should probably award karma in the same way approveSuggestion does: only if the message was not previously current and the reviewer is not the translator.
[08:49] <jtv> henninge: maybe updateTranslation would be a fit for what you're doing.  That also follows the "if it's diverged, and the new translation is not identical to the shared one, keep diverged" rule.
[08:50] <henninge> jtv: oh, I have to add the "is not identical" ...
[08:52] <henninge> jtv: and that is not something "approveAsDiverged" does?
[08:52] <henninge> diverged = suggestion.is_diverged
[08:52] <henninge> jtv: ^ Can a suggestion actually be diverged?
[09:04] <mrevell> Hi
[09:10] <adeuring> good morning
[09:19] <jtv> henninge: a suggestion can be diverged _in another template_.
[09:20] <jtv> henninge: as for approveAsDiverged: that method is for explicitly diverging a message.  It always diverges (except where you're actually trying to set the shared translation as a diverged translation).
[09:20] <jtv> but setCurrentTranslation checks if the current message is diverged and if so, maintains divergence.  (Again of course, except if the new translation is identical to the current shared one)
[09:27] <henninge> jtv: I don't like setCurrentTranslations because it expects strings ... ;(
[09:28] <henninge> which is kind of dumb, considering that I already have a message, and msgstr objects and all that.
[09:28] <henninge> that's why I'd prefer using approve
[09:28] <henninge> approveSuggestion
[09:28] <jtv> henninge: shouldn't be that hard to change—it's only used by tests, and other methods that can look up the POTranslation objects.
[09:29] <jtv> I'm not saying you have to use it, but have a look if it serves your needs otherwise.
[09:30] <henninge> jtv: well, "approveSuggestion" is really only a wrapper around setCurrentTranslation
[09:30] <henninge> plus karma assignment
[09:31] <henninge> jtv: So, I guess I don't need to check for divergence - submit suggestion will DTRT?
[09:32] <jtv> submitSuggestion can't
[09:33] <jtv> But I see what you mean—approveSuggestion maintains divergence.
[09:34] <jtv> I do see one other thing that approveSuggestion probably should do: disable a diverged message in the same pofile that may be masking the suggestion.
[09:35] <jtv> It shortcuts the case where the suggestion is already current.  It probably shouldn't, though of course not shortcutting does mean that the karma assignment needs a bit of extra care.
[09:36] <jtv> But yes, this means that in principle approveSuggestion is good enough for imports.  No need for approveAsDiverged.
[10:07] <jml> rockstar, https://dev.launchpad.net/LEP/BetterPrivacy, https://dev.launchpad.net/LEP/BugzillaComponents and https://dev.launchpad.net/LEP/BuildFarmScalability all spring to mind
[11:26] <henninge> jtv: I think approveSuggestion may have gotten the Karma handling wrong.
[11:26] <henninge> jtv: this is from the failing test: http://paste.ubuntu.com/495203/
[11:29] <jtv> henninge: I can see how that's different from what approveSuggestion does, but how is what approveSuggestion does wrong?
[11:29] <henninge> jtv: well, different from documentation == wrong
[11:29] <henninge> ;-)
[11:29] <jtv> This pastebin leaves me with the impression that updateTranslation gets it wrong
[11:30] <henninge> that is possible
[11:31] <henninge> jtv: should a translator not get karma twice -- once for suggesting and once for suggestion being approved?
[11:31] <jtv> a translator, yes
[11:31] <jtv> but if it's the same person approving that same translation?
[11:31] <jtv> That seemed wrong to me.
[11:32] <henninge> jtv: so, what is karma trying to show?
[11:32] <jtv> It is trying to reward people for doing useful things.
[11:33] <jtv> I'm trying to find something wrong with my own earlier reasoning, but not finding anything so far.
[11:34] <jtv> Yes, it does mean that a reviewer can hope to gain more karma from translating in translation mode—_if_ they can get those suggestions reviewed by someone else.
[11:34] <jtv> I don't think that's a bad thing.
[11:34] <henninge> A translator that translates 10 strings that are all approved by a reviewer will get twice as much karma as a reviewer that enters the same translations directly.
[11:35] <jtv> I think that's actually rewarding good behaviour.
[11:35] <jtv> At first glance it seems to increase the risk of those translations staying unapproved.  But the author doesn't get the extra karma until they are.
[11:36] <jtv> So a proper, well-motivated karma whore will try to get them reviewed.
[11:36] <henninge> In total, a suggested-approved translation will deal out three times as much karma as a directly-approved will.
[11:37] <jtv> To different people.
[11:37] <henninge> jtv: I am just finding reasons, trying to understand. I am not against your reasoning.
[11:37] <jtv> That's fine.
[11:37] <henninge> So I should update the test.
[11:37] <jtv> I think so, yes.
[11:38] <jtv> BTW dogfood is being upgraded to lucid.  It'll take about an hour.
[11:39] <henninge> So far, imported translation would give the uploader "translationsuggestionapproved" karma, now they will get "translationsuggestionadded" karma.
[11:39] <henninge> Are they weighed differently?
[11:39] <jtv> Don't know.
[11:40]  * henninge consults launchpad_dev
[11:42] <henninge> jtv: http://paste.ubuntu.com/495216/
[11:43] <jtv> henninge: thanks for digging that up!
[11:43] <henninge> looks like we have some more karma actions ...
[11:43] <jtv> BTW another way of looking at the current karma design is, "karma shouldn't reward people for joining a translation team just to translate."
[12:04] <deryck> Morning, all.
[12:14] <jml> deryck, good morning
[12:26] <jml> I'm going to head out to Foyles and see if I can pick up a book on queueing theory
[14:41] <jml> hello
[14:45] <bigjools> does the .dev instance run with multiple request threads?
[14:49] <salgado> bigjools, yes
[14:50] <bigjools> salgado: cool thanks
[14:51] <bigjools> now I have a fighting chance of re-creating my concurrency issue
[15:05] <bigjools> salgado: do you have any clue how I could write a test case that simulates simultaneous requests in 2 threads?
[15:06] <salgado> bigjools, I think the test suite runs single threaded
[15:06] <bigjools> yeah, that's why I asked :)
[15:09] <jml> bigjools, I guess it all depends on how the test browser works
[15:10] <bigjools> jml: I've only ever seen it manage single-threaded stuff
[15:11] <bigjools> jml: I've re-created an issue locally where I need to bash the copy button on the PPA copy page as fast as I can
[15:11] <jml> bigjools, well, I don't know how it works. It might just be that all you need to do is spawn two threads each of which has its own test browser
[15:12] <jml> bigjools, hmm.
[15:12] <jml> bigjools, in that case, you might not even need to worry about the test browser
[15:12] <bigjools> jml: that's one way but it seems as though it might not be deterministic
[15:12] <jml> bigjools, you are using threads, kiss determinism goodbye
[15:12] <bigjools> that's why I said "simulate" in my original question :)
[15:13] <jml> bigjools, then what's the problem with spawning two threads and using the test browser?
[15:13] <jml> bigjools, or, actually
[15:13] <jml> bigjools, you don't need the test browser, you just need to have instantiated view objects pointing to the same store
[15:13] <bigjools> I'm starting to think that a test case is not worth it
[15:13] <jml> bigjools, hang on
[15:13] <jml> bigjools, is this for debugging the problem or writing a test?
[15:13] <bigjools> a test
[15:13] <bigjools> I know what the problem is, I think
[15:14] <bigjools> the two transactions don't clash at all, so don't trigger a serialization issue
[15:14] <bigjools> but the checks that are made work once one of them is committed
[15:14] <jml> bigjools, otp
[15:14] <bigjools> so I have an evil plan to make them clash some how
[15:15] <bigjools> ok
[15:32] <rockstar> jml, did you see my LEP?
[15:33] <jml> rockstar, I saw that it exists. still otp.
[15:35] <rockstar> jml, ack.
[15:52] <jml> bigjools, do you know off the top of your head what times the Walter de Cantelupe is closed on Sundays?
[15:54] <bigjools> jml: late
[15:54] <bigjools> usually ~11 I think
[15:54] <bigjools> but if you're going to be late I'd call and let him know
[15:55] <jml> bigjools, istr Martin saying that it's closed for some time during the afternoon
[15:55] <jml> bigjools, I'll be arriving at ~6pm
[15:56] <bigjools> jml: I'd call him then, yes it is closed in the afternoons, I can't remember what time it opens
[15:56] <jml> bigjools, will do.
[15:56] <jml> bigjools, thanks
[15:57] <bigjools> np
[16:20] <jml> grr.
[16:42] <jml> Do you know what would make most technology better?
[16:42] <jml> Actually working.
[17:14] <jml> rockstar, I just scribbled all over https://dev.launchpad.net/Code/MergeQueues/LEP
[17:14] <jml> rockstar, basically adding more details in the requirements.
[17:14] <rockstar> jml, great, I'll take a look.
[17:20] <rockstar> jml, ah, yeah, most of those details we've already addressed in my notes at https://dev.launchpad.net/Code/MergeQueues but I'm happy to LEPify them.
[17:21] <jml> rockstar, yeah. I see the notes cover similar ground in story format.
[17:21] <jml> rockstar,
[17:22] <jml> rockstar, but I want to get it down in a requirements format
[17:22] <rockstar> jml, absolutely.  abentley and I were just going over the recipe LEP and reviewing what else needs to be done, so I'm identifying what is important about a LEP.
[17:23] <jml> rockstar, cool.
[17:24] <jml> rockstar, also, I'm really keen to see thoughts on the full cycle of any given feature: how do people find out about it; how does one use it for the very first time; how does one know it's safe to try out; what do the inner cycles look like; how does one  stop using it? etc
[17:24] <rockstar> jml, yeah, and I think we're going to identify much of that with our UI mockups.
[17:24] <jml> rockstar, agreed
[17:24] <rockstar> (I have a list of them I need to do)
[17:25] <jml> rockstar, it's easy to let UI mockups focus on the inner bits of the workflow rather than a more broad context, so just flagging now
[17:26] <rockstar> jml, yeah, I actually like to address the more broad context in UI mockups.  They should be a general idea, not the final UI.
[17:26] <jml> rockstar, also, I noticed on your notes page that you're thinking of having something on the branch page that says the branch isn't managed by a queue
[17:26] <rockstar> The final UI gets sorted as you actually implement the feature and find out what works.
[17:26] <jml> rockstar, for a project that uses feature branches, that's going to be irrelevant for most branches.
[18:01]  * gmb EoWs. Night folks.
[19:35] <lifeless> bac: hi, around?
[19:36] <bac> hi lifeless
[19:36] <lifeless> rev 11552 on stable
[19:36] <lifeless> I'm not clear if that is ok to deploy to lpnet now, or not.
[19:38] <bac> lifeless: b/c it is qa-untestable or b/c of pre-requisite branches
[19:38] <lifeless> because of the description
[19:38] <lifeless> 'show xx on lpnet'
[19:38] <lifeless> I don't know if you intend that to wait for the next release
[19:38] <lifeless> or if showing it on Monday would be ok.
[19:39] <bac> lifeless: Monday is great
[19:39] <lifeless> ok, cool
[19:39] <lifeless> we're not qa'd all the way up to it, but as things move forward...
[19:39] <bac> lifeless: we should have rolled it in 10.09 but it slipped my mind
[19:39] <lifeless> Ursinha-lunch: hiya
[19:39] <lifeless> bac: feature flags will help :)
[19:39] <bac> lifeless: yes, they just weren't ready at the time...
[19:42] <bac> lifeless: why do you do the endwith test at line 27 of https://code.edge.launchpad.net/~lifeless/launchpad/registry/+merge/35774
[19:43] <lifeless> completeness
[19:43] <bac> lifeless: but when would it not pass?
[19:43] <lifeless> oh ahh
[19:44] <lifeless> thats a bug, I meant to put %3f or whatever in there.
[19:44] <lifeless> I'll come back to it, its already in ec2 land - thanks for noticing.
[19:44] <bac> ok, i wasn't sure if it was a bug or you were doing something clever
[19:45] <lifeless> very very clever
[19:45] <lifeless> so clever you put a tail on it and call it a ferret
[20:27] <Ursinha> lifeless, hi
[20:38] <lifeless> Ursinha: hi there
[20:38] <lifeless> uhm, /me pages in
[20:38] <lifeless> Ursinha: oh right, tagger stuff - how goes it? Anything blocking you?
[20:45] <Ursinha> lifeless, I'm not blocked on anything right now
[20:46] <Ursinha> lifeless, more trying to figure out how to solve the mess unique branches for several bugs introduced to the scenario :)
[20:48] <lifeless> heh, sorry ;)
[20:57] <lifeless> grah
[20:57] <lifeless> ec2 fail
[20:57] <lifeless>  File "./test_on_merge.py", line 50, in setup_test_database
[20:57] <lifeless>    con = psycopg2.connect('dbname=template1')
[20:57] <lifeless> psycopg2.OperationalError: could not connect to server: No such file or directory
[20:57] <lifeless>        Is the server running locally and accepting
[20:57] <lifeless>        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
[21:55] <lifeless> ok, is the AMI bust or something?
[21:56] <lifeless> I'm getting pg not connected errors consistently on ec2land
[21:56] <lifeless> mars: ^
[21:56] <lifeless> # Run all tests. test_on_merge.py takes care of setting up the
[21:56] <lifeless> # database.
[21:56] <lifeless> /var/launchpad/test/bin/py -t ./test_on_merge.py -vv "--subunit -vvv"
[21:56] <lifeless> Traceback (most recent call last):
[21:56] <lifeless> ...
[21:56] <lifeless>  File "./test_on_merge.py", line 50, in setup_test_database
[21:56] <lifeless>    con = psycopg2.connect('dbname=template1')
[21:56] <lifeless> psycopg2.OperationalError: could not connect to server: No such file or directory
[21:56] <lifeless>        Is the server running locally and accepting
[21:56] <lifeless>        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
[22:51] <maxb> What is the status of Python 2.6 / datacentre lucid upgrades these days?
[22:51] <Ursinha> lifeless, help me with something here
[22:53] <Ursinha> lifeless, latest deployed revision from stable on lpnet was 11515, now the script states it's 11546
[22:54] <Ursinha> while True: head -> desk
[22:58] <lifeless> Ursinha: heh
[22:58] <Ursinha> lifeless, no, not funny
[22:58] <lifeless> Ursinha: looking at stable branch ?
[22:58] <Ursinha> deployments.check_status() is returning that revision as latest deployed
[22:58] <lifeless> thats right
[22:58] <Ursinha> production-stable
[22:58] <lifeless> its looking at the branch
[22:58] <lifeless> its correct; it goes live Monday
[22:59] <Ursinha> wait, what goes live Monday
[22:59] <lifeless> check LaunchpadProductionStatus
[22:59]  * Ursinha looks
[23:00] <lifeless> jelmer: you need to update that page now you've landed your branch on production-devel
[23:00] <lifeless> Ursinha: under 'requested cherrypicks'
[23:00] <Ursinha> lifeless, oh
[23:01] <Ursinha> so production-stable already has that
[23:01] <Ursinha> ?
[23:01] <lifeless> yes
[23:01] <Ursinha> ah
[23:01] <Ursinha> *whew*
[23:01] <lifeless> working as designed
[23:01] <Ursinha> I was about to kill someone
[23:01] <lifeless> its not live on the appserver because doing it friday isn't the smartest thing for a big merge like that
[23:01] <lifeless> not when we were low-losa to boot
[23:02] <lifeless> jcsackett: ping
[23:02] <lifeless> https://bugs.edge.launchpad.net/launchpad-registry/+bug/597738
[23:02] <lifeless> thats the next blocking unqa'd commit
[23:02] <jcsackett> the one for bugs?
[23:02] <lifeless> jcsackett: rev 11547
[23:02] <lifeless> jcsackett: but the process looks at a whole bug, not one branch-for-it.
[23:03] <lifeless> jcsackett: its qa-needstesting at the moment, if the bugs bits are doing what they should on staging/edge, please qa-ok it
[23:03] <Ursinha> do that and I will run the script
[23:03] <jcsackett> i can ping EdwinGrubbs about the branch he landed to QA; the remaining hasn't reached fix-committed yet. Blueprints should be through buildbot shortly.
[23:04] <lifeless> jcsackett: 11547 is what I care about right now.
[23:04] <Ursinha> jcsackett, so it's part of a larger fix?
[23:04] <lifeless> in general its a bit odd to do what this bug is doing
[23:04] <sinzui> I QAed bugs yesterday and reported bugs.
[23:04] <lifeless> sinzui: so should it be qa-bad ?
[23:04] <sinzui> no
[23:04] <sinzui> it is still an improvement
[23:04] <lifeless> so its qa-ok?
[23:04] <EdwinGrubbs> jcsackett: my branch was qa'ed fine. I didn't update the bug since it is is just going back to qa-needstesting when the next bugtask is completed.
[23:04] <sinzui> yes
[23:05] <Ursinha> cool
[23:05] <lifeless> EdwinGrubbs: it needs to go to qa-ok to deploy
[23:05] <jcsackett> EdwinGrubbs: okay, i thought you already had done that.
[23:05] <lifeless> otherwise it blocks all commits after it
[23:05] <Ursinha> EdwinGrubbs, you can tag the bug when your branch lands
[23:05]  * sinzui found to pre-existing issues that must be fixed to say bridging-the-gap is done
[23:05]  * jcsackett is confused about the QA process.
[23:05] <EdwinGrubbs> oh, I forgot about that.
[23:05] <jcsackett> are we not supposed to use needstesting anymore?
[23:05] <lifeless> jcsackett: yes, you should. You should also test asap.
[23:06] <Ursinha> jcsackett, yes, of course :) but you're saying qa-needstesting for a branch
[23:06] <sinzui> Wake up, QA
[23:06] <lifeless> jcsackett: https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt
[23:06] <Ursinha> you landed a branch that fixes your bugtask in that bug, that lands, it's marked qa-needstesting for your landing
[23:06] <sinzui> notice staging updates QA...QA is the fastest way to unblock the team
[23:06] <lifeless> or on edge
[23:06] <jcsackett> okay, that all jives with what i thought. have caught bits and pieces of conversations today that have left me off kilter. :-P
[23:06] <EdwinGrubbs> jcsackett: I just treated this bug differently since it has multiple bugtasks. I didn't think about how it needs to go to qa-ok temporarily even though it will go to qa-needstesting when the next branch lands.
[23:06] <lifeless> because edge runs stable
[23:06] <sinzui> We were 3 hours from exceeding our limits 3 days ago
[23:07] <lifeless> EdwinGrubbs: I would have done multiple bugs for this thing
[23:07] <lifeless> because the work going on in each one is different
[23:07] <EdwinGrubbs> yes, hindsight is 20/20
[23:08] <lifeless> never too late to change ;)
[23:09] <lifeless> anyhow yes, this isn't a big issue
[23:09] <lifeless> we're changing process
[23:09] <lifeless> so we're going to have muscle memory to unlearn and so on
[23:09] <jcsackett> i'll keep this in mind tomorrow--the blueprints task should be ready to qa then.
[23:10] <sinzui> I think the registry team can take ownership of EmailAddress if the foundations team have given up using the table for SSO
[23:12] <lifeless> wgrant: please qa https://bugs.edge.launchpad.net/soyuz/+bug/564491
[23:12] <lifeless> wgrant: and https://bugs.edge.launchpad.net/soyuz/+bug/566339
[23:13] <Ursinha> lifeless, so I cannot mark that bug as qa-ok?
[23:14] <lifeless> Ursinha: I don't know
[23:14] <lifeless> Ursinha: hang on, which bug :)
[23:14] <Ursinha> hehe
[23:14] <Ursinha> https://bugs.edge.launchpad.net/launchpad-registry/+bug/597738
[23:14] <Ursinha> the one holding the script
[23:14] <lifeless> jcsackett: so
[23:15] <lifeless> nvm
[23:15] <lifeless> Ursinha: yes, sinzui said its ok
[23:15] <Ursinha> hehe, cool
[23:15]  * sinzui just changed is since his team are too frightened to say it is okay
[23:16] <Ursinha> oh, I've done that too
[23:16] <lifeless> Ursinha: I expect it to stop at 11556
[23:16] <Ursinha> let's see
[23:16] <sinzui> Ursinha, while I promised flacoste that I would let my team do QA, I need to schedule work. I qa every morning, even weekends, and I mark something bad if it really is bad
[23:16] <Ursinha> even weekends
[23:17] <sinzui> Ursinha, The delay is waiting for a registry developer to do his part
[23:17] <sinzui> I have to review projects on the weekend too
[23:17] <Ursinha> lifeless, that's correct, it stopped at 11556
[23:19] <lifeless> Ursinha: still, thats another good batch of revs to land
[23:19] <Ursinha> yeag
[23:19] <Ursinha> yeah
[23:20] <lifeless> sinzui: all teams are going to have to tune their processes, I wouldn't stress about it
[23:20] <lifeless> sinzui: it'll become very clear the shorter the pipeline to production gets
[23:21] <lifeless> sinzui: and once we stop edge autodeployments in favour of QA on stagingqa
[23:24] <sinzui> lifeless, I think there is resistance to interrupting a task. When you are coding the a branch waiting for to QA your work, you must be will to stop coding when that work come to QA. Our team hit the QA limit twice last release Bac had to remind me that staging updated a few days ago so that he cold move a card
[23:28] <lifeless> sinzui: that makes sense to me; but the price for avoiding that interrupt is a massive team wide interrupt every month, which everyone agrees they like less
[23:30] <sinzui> As you can image, I have a very set pattern in the morning, lunch, and evening. I look like I am on top of things, but I just schedule repetitive tasks like QA and question every few hours
[23:31] <lifeless> sinzui: I think if everyone looked for QAable stuff at the start of work, after lunch, and before signing off, we'd be in good shape
[23:32] <lifeless> https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=qa-needstesting,qa-bad
[23:33] <lifeless> thats one thing for every 2 people: not terrible, but not brilliant either
[23:33] <lifeless> jcsackett: https://bugs.edge.launchpad.net/launchpad-registry/+bug/576757
[23:34] <jcsackett> lifeless: qaing it as we speak, actually. :-P
[23:34] <sinzui> lifeless, we are doing that one now
[23:34] <lifeless> \o/
[23:34] <sinzui> jinx
[23:34] <lifeless> is there some other channel where you coordinate this?
[23:35] <sinzui> lifeless, @lp-registry explaining how I pick a victim to test with can be a delicate subject
[23:35] <jcsackett> lifeless: when i have no earthly idea how to set up the conditions to test i bug sinzui in another channel. :-)
[23:35] <sinzui> #lp-registry
[23:35] <lifeless> public or private?
[23:36] <sinzui> lifeless, private
[23:37] <Ursinha> I'm heading for the weekend
[23:37] <Ursinha> will return later
[23:37] <lifeless> sinzui: I'll hang out there if its ok; I may every now and then point stuff to this channel (I think we do way to much on the quiet). But you can tell me if I'm wrong :)
[23:37] <lifeless> Ursinha-afk: ciao
[23:43] <lifeless> Question:+huge-vocabulary 50.67 <-99% under
[23:43] <lifeless> wheee
[23:43] <jcsackett> alright, that's both of the bugs i can hit qa'ed. off to the weekend.
[23:43] <lifeless> ciao
[23:43] <jcsackett> g'night.