[03:11] <rick_h__> wgrant: ping
[03:12] <wgrant> rick_h__: Hi
[03:12] <rick_h__> wgrant: hey, saw your bug. I've got a fix I'm trying to land for that, but it got rejected by pqm for a bad commit message regex
[03:13] <wgrant> rick_h__: PQM is in testfix because of a bad db-devel landing.
[03:13] <rick_h__> with the lack of rollouts over friday/weekend it was decided to not rollback, just land
[03:13] <rick_h__> ah, so that's what it's saying
[03:13] <wgrant> OK.
[03:13] <wgrant> Let's cheat.
[03:13] <wgrant> If we force db-devel to build, you can land stuff until it fails again.;
[03:13] <rick_h__> wgrant: https://code.launchpad.net/~rharding/launchpad/link_tags_894726 has the fix
[03:14] <wgrant> It's forced -- try landing again at :21 or so
[03:14] <rick_h__> wgrant: ah ok. Will get that ready then
[03:14] <rick_h__> now this is just via a pqm land right? bypassing ec2?
[03:14] <wgrant> Yep
[03:14] <wgrant> Use bzr lp-land
[03:14] <wgrant> Or bzr pqm-submit directly, if lp-land doesn't work.
[03:14]  * rick_h__ hasn't tried that out yet
[03:15] <rick_h__> will do
[03:15] <wgrant> Use bzr lp-land just like ec2 land
[03:15] <wgrant> Or pqm-submit like 'bzr pqm-submit -m "[r=foo][bug=bar] blah blah blah"'
[03:16] <rick_h__> ok, will try bzr lp-land in a few then.
[03:16] <wgrant> Great.
[03:27] <rick_h__> wgrant: "bzr: ERROR: No PQM submission email address specified for" quick search finds a request to add a feature to bzr, nothing in dev.lp.net?
[03:27] <wgrant> rick_h__: Hm, if you're using the directory structure generated by rocketfuel-setup that should work.
[03:28] <wgrant> Otherwise --public-location=bzr+ssh://bazaar.launchpad.net/~rharding/launchpad/link_tags_894726 --submit-branch=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel
[03:28] <rick_h__> yea, that's how I got things started...ok will poke at it.
[03:28] <wgrant> Give those two options to pqm-submit as well.
[03:29] <rick_h__> wgrant: ok, running
[03:29] <rick_h__> yea, same email error
[03:29] <rick_h__> sorry, that's from the bzr pqm-submit, let me try the other
[03:29] <wgrant> Oh.
[03:29] <wgrant> email address
[03:29] <wgrant> Hm
[03:29] <wgrant> You are running it from the right directory, right? :)
[03:30] <rick_h__> yea, same...grr
[03:30] <rick_h__> /home/rharding/launchpad/lp-branches/link_tags_894726
[03:30] <wgrant> Hmm
[03:30] <wgrant> Does your ~/.bazaar/locations.conf have a 'pqm_email' set?
[03:31] <rick_h__> no, nothing there
[03:31] <wgrant> Huh
[03:31] <wgrant> rocketfuel-setup should have set that up.
[03:31] <wgrant> I think.
[03:31] <wgrant> Maybe not.
[03:32] <wgrant> http://pastebin.ubuntu.com/773959/ is what I use
[03:32] <rick_h__> yea http://doc.bazaar.canonical.com/plugins/en/pqm-plugin.html seems to imply I need a bunch of stuff
[03:33] <wgrant> You probably already have the second part of that.
[03:33] <rick_h__> yea, just missing the email bits
[03:34] <rick_h__> ok, got something going. lp-land still hates me, but the manual command with paths ran
[03:35] <wgrant> Heh
[03:35] <rick_h__> can I manually change the tag then on the bug from qa-bad?
[03:35] <wgrant> It's complicated™
[03:35] <wgrant> It's technically not qa-bad.
[03:35] <wgrant> Because we already deployed it, but disabled the feature.
[03:36] <wgrant> So yes, it's no longer qa-bad.
[03:36] <rick_h__> yea, I seemed to have done this a bit wrong from the start unfortunately :/
[03:36] <wgrant> qa-tagger will automatically reset it to qa-needstesting once this lands.
[03:36] <rick_h__> ah ok then
[03:36] <wgrant> Meh, our QA workflow was designed before feature flags.
[03:36] <wgrant> Nobody is quite sure how it works in this situation :)
[03:36] <rick_h__> I wasn't sure if pqm would even try this since it was qa-bad already
[03:36] <wgrant> PQM doesn't know about any of that.
[03:36] <rick_h__> gotcha, still figuring out the moving parts. Just a few of them :)
[03:37] <wgrant> Yeah :/
[03:37] <rick_h__> It's nice to have the whole process, but sometimes miss $ ssh server && git pull
[03:38] <wgrant> Yeeeeeees.
[03:38] <rick_h__> thanks for the help wgrant and the link to the pystache fix. I had missed that.
[03:38] <wgrant> np
[03:38] <rick_h__> I really hate that thing, but can't find anything else with both server/clide side use :(
[03:39] <wgrant> Yeah :/
[03:39] <wgrant> It seems to work mostly.
[03:39] <rick_h__> yea, but it's got a lot of issues to watch out for like this
[03:39] <rick_h__> love that there's a branch named "spec-compliant"
[03:39] <wgrant> Heh
[03:40] <rick_h__> kind of would hope that would be called ...oh... "master"
[03:40] <rick_h__> sweet, pqm emails say merged
[03:40] <wgrant> You would think so :)
[03:40] <wgrant> Excellent!
[07:05] <lifeless> right, mail sent
=== _thumper_ is now known as thumper
[21:51] <wallyworld_> lifeless: you around for a quick question?
[22:48] <wgrant> wallyworld_: He's not here this week.
[22:49] <wgrant> StevenK: around?
[22:50] <wallyworld_> wgrant: you weren't online yet :-) i just wanted to know, how to fix the deployment report to link rev 14540 as fixing qa-bad rev 14526
[22:50] <wgrant> That's a trick question.
[22:50] <wgrant> 14526 isn't really qa-bad
[22:50] <wallyworld_> it's marked as qa-bad
[22:50] <wgrant> But it's a lie :)
[22:51] <wgrant> Hmm.
[22:51] <wgrant> Perhaps not.
[22:51] <wallyworld_> if it were qa-bad, and a subsequent rev was landed without the correct tag, how do we fix that?
[22:51] <wgrant> rick_h__ confused me yesterday.
[22:51] <wgrant> I thought the bug listing beta was disabled so we could deploy that revision anyway.
[22:51] <wgrant> But that revision is not deployed.
[22:51] <wallyworld_> ie to say that once 14540 is ok, so too is 14526
[22:51] <wgrant> Which must mean there's another bad revision that caused the beta bug listings to be disabled.
[22:52] <wgrant> wallyworld_: There's no way to do that.
[22:52] <wgrant> You have to lie that one of them is qa-ok, or just pretend that the deployment report is green.
[22:52] <wallyworld_> normally, landing a subsequent rev is rollback-xxx is the right thing to do, no?
[22:52] <wallyworld_> s/is/with
[22:52] <wallyworld_> rollback=xxx i mean
[22:53] <wallyworld_> i'm keen to get my rev 14528 deployed since it fixes a regression
[22:54] <wgrant> "normally"" == if you want to wait 13 hours
[22:54] <wgrant> Which you don't.
[22:54] <wgrant> So normally doesn't apply here.
[22:55] <wallyworld_> what i meant was, rev 14540 should have been landed with rollback=14526
[22:55] <wgrant> Ah, yes, probably.
[22:55] <wgrant> But I was under the impression that the earlier rev was already deployed.
[22:56] <wallyworld_> and since it wasn't i wanted to fix but it seems we can't do that from what you said above
[22:56] <wgrant> You can't, no.
[22:57] <wallyworld_> and it seems we can't deploy for a while then since there's a lot on un-qaed revs between 14526 and 14540
[22:57] <wallyworld_> so my regression fix will have ot wait :-(
[22:57] <wgrant> I also don't know why the bug listings are disabled.
[22:58] <wallyworld_> i thought there was an issue (which i can't recall) hence they were to only be for ~launchpad-beta
[22:59] <wallyworld_> are they now disabled for everyone?
[23:00] <wgrant> They're disabled for everyone.
[23:00] <wgrant> They're not out of beta yet.
[23:00] <wgrant> Still ages away from being ready.
[23:01] <wallyworld_> wgrant: so there must have been an issue then that cause them to be turned off since i joined the team which allowed me to see them
[23:01] <wallyworld_> and they are due out of beta this week afaik
[23:02] <wgrant> due, yes :)
[23:02] <wgrant> Many things have been due out of beta before.
[23:03] <wallyworld_> we'll see then i guess. it did appear to all be under control