[00:39]  * thumper just found another mock logger
[00:39]  * thumper sighs
[01:04] <thumper> holy crap, two more logger classes slaughtered
[01:06] <StevenK> thumper: How many is that now? Six?
[01:07] <wgrant> https://code.launchpad.net/~registry/+junk/devel-1
[01:07] <thumper> about four general loggers, and 6 mock loggers
[01:07] <wgrant> How did that branch end up there?
[01:07] <wgrant> Maybe it was attached to a deleted team.
[01:07] <wgrant> (the registrant wants it deleted, but I want to investigate a bit first)
[01:09] <thumper> and add another logger class
[01:09] <wgrant> Fun.
[01:10] <thumper> oh and another
[01:10] <StevenK> Eight?
[01:11] <StevenK> How many loggers does our codebase need?
[01:11] <wgrant> MORE!
[01:11] <thumper> and another
[01:11] <thumper> and guess how many were in soyuz?
[01:11] <wgrant> 99.9%
[01:11] <wgrant> With the other one being in archivepublisher.
[01:12] <thumper> wgrant: one was in the job test runner module
[01:12] <thumper> but it would be a curious thing to count them all
[01:12] <wgrant> :(
[01:12] <thumper> found the extras by grepping for 'def debug'
[01:12] <wgrant> Gnrrrrgh.
[01:13] <wgrant> Why has that related branches rollback not landed yet......
[01:13] <thumper> is there a way to just run all the tests that you've modified?
[01:14] <wgrant> bzr st | sed | xargs ...
[01:14] <wgrant> So, no.
[01:16] <StevenK> thumper: I'd be curious to find out after you've finished how many lines you've removed and added
[01:16] <thumper> well, changed a lot
[01:37] <poolie> thumper: are you here?
[01:37] <thumper> yes
[01:38] <poolie> can we decide about the rlimit thing? it sounds like we should just reject that patch until somebody does a larger reconsideration of the job system?
[01:38] <thumper> I think so
[01:38] <poolie> ok
[01:38] <thumper> until we know that a job killed by rlimit x number of times will stop trying to run
[01:39] <poolie> shall we file a bug or something for that, or would it be too vague (or a dupe)
[01:39] <thumper> I think we should file a bug
[01:39] <thumper> I don't know of one
[01:39] <thumper> something along the lines of "job attempts should be incremented on acquisition"
[01:40] <poolie> ok, i'll do that
[01:40] <poolie> perhaps also resource limits should be in the job framework and dynamically configured
[01:50] <LPCIBot> Project db-devel build (242): FAILURE in 3 hr 39 min: https://hudson.wedontsleep.org/job/db-devel/242/
[01:51] <wgrant> No traceback...
[01:54] <thumper> poolie: yes, I agree that rlimits should be part of the job framework
[01:55] <poolie> done, and rejected
[01:55] <poolie> ok
[01:55] <poolie> we'll see if it gets to the top of the losa pain stack
[01:55] <poolie> it's probably not there now
[01:55] <wgrant> thumper: The db-devel failure is translations stuff wanting one of your ex-loggers.
[01:55] <wgrant> thumper: Do you want to fix, or shall I?
[01:56] <thumper> error?
[01:56] <wgrant> lib/lp/translations/tests/../doc/poimport-script.txt
[01:56] <wgrant>       File "<doctest poimport-script.txt[26]>", line 1, in <module>
[01:56] <wgrant>         from canonical.launchpad.scripts import FakeLogger
[01:56] <wgrant>     ImportError: cannot import name FakeLogger
[01:57] <thumper> I can fix
[01:57] <wgrant> Thanks.
[01:59]  * wgrant rolls back 12111, since abentley's rollback seems to have vanished.
[03:11] <wgrant> thumper: Now that we are hopefully out of testfix, can I have your rs to rollback 12111?
[03:11] <wgrant> It is qa-bad.
[03:15] <lifeless> wgrant: you don't need reviews to do that
[03:15] <wgrant> lifeless: Even though I'm not a reviewer?
[03:16] <wgrant> OK.
[03:21] <wgrant> Nooooo.
[03:25] <wgrant> And this has missed the next buildbot run. Woo.
[03:25] <wgrant> lifeless: This process is broken. Can we please discuss at the epic how to fix it?/
[03:28] <lifeless> wgrant: its a separate process
[03:29] <lifeless> wgrant: that bit isn't broken AFAIK
[03:31] <lifeless> lp-land --rollback as pre the wiki page
[03:32] <wgrant> lifeless: I mean the exceptional changes process.
[03:33] <wgrant> At the moment it is a race against the bug jam's bugs jamming up deployment for days.
[03:33] <wgrant> If we have one more broken revision, recipes remain broken until the 4th of January.
[03:33] <wgrant> There is clearly something very wrong here.
[03:35] <lifeless> we shouldn't be landing quite so many broken revs either ;)
[03:36] <wgrant> Breakage happens. The process needs to deal with it.
[03:36] <lifeless> i know
[03:36] <lifeless> that was part of the original analysis
[03:36] <lifeless> that we need to rollback rather than blocking for 4 weeks at a time ;)
[03:36] <lifeless> the other option is to start uncommitting
[03:37] <lifeless> which I'm a little less keen on
[03:37] <wgrant> Even rolling back doesn't help.
[03:37] <wgrant> Unless you QA before anything else lands.
[03:39] <wgrant> Easy improvements to this particular case would be to have obvious extensions to the qa-tagger-based production change approval policy. eg. two broken webapp revisions shouldn't block a rollout to cesium for days, because that is insane.
[03:39] <wgrant> But I do not know how to fix the general case.
[03:56] <poolie> wow, this guy who keeps uploading his private key/s
[03:56] <poolie> i'm kind of scared what will happen once he does get them going
[03:57] <wgrant> It is slightly disturbing.
[03:58] <wgrant> I've only seen the one so far, though.
[03:59] <wgrant> Oh, there's another one.
[03:59] <poolie> he attached at least two private keys (or maybe the same key twice) plus one revocation certificate
[03:59] <wgrant> Missed that.
[04:01] <wgrant> The revocation certificate is at least for one of those two keys, and not a third.
[04:32] <lifeless> wgrant: rollback does help, it reduces the window from detection + fix + ec2 + pqm + buildbot
[04:33] <lifeless> wgrant: to detection + pqm + buildbot
[04:33] <lifeless> s/window/latency
[04:33] <lifeless> the *window* becomes
[04:33] <lifeless> detection + pqm
[04:33] <lifeless> which should be very narrow if folk are doing QA as top priority.
[04:34] <lifeless> wgrant: I'll be delighted to discuss at the epic, or before (in the new year)
[04:35] <lifeless> wgrant: as for deploying delta'd versions: thats a high risk thing to do; I don't like the idea of it being defacto 'oh the webapp qa has 'issues''
[04:35] <lifeless> wgrant: other layers are equally liable to fritz, and its not clear that we have the support framework to deal with N-ary delta skew *and* achieve a high velocity
[04:37] <wgrant> Hmmm.
[04:37] <lifeless> until everyone is qaing first, coding etc second
[04:37] <lifeless> we haven't really tried the process completely
[04:38] <wgrant> True.
[04:38] <lifeless> I'm open to radical further changes, or whatever really, as needed to fiux.
[04:38] <lifeless> but I'd like to prove that it cannot work easily and effectively first
[04:38] <wgrant> Test suite parallelisation may make it all work a lot better.
[04:39] <wgrant> As landing and QA will be possible within a working day.
[04:39] <lifeless> as will lighter tests
[04:39] <lifeless> my goal is 4 hour TTL for changes
[04:39] <wgrant> At the moment only Soyuz can QA within 8-10 hours of landing :(
[04:40] <lifeless> huh? what do you mean
[04:40] <lifeless> do you mean 'only soyuz cannot' ?
[04:40] <wgrant> Only Soyuz can, because we have DF.
[04:40] <wgrant> Everyone else has to wait for EC2 + PQM + buildbot + qastaging
[04:40] <lifeless> everything else has qastaging
[04:40] <lifeless> df has to wait for buildbot too
[04:41] <lifeless> qa staging is 15 minute cycle IIRC
[04:41] <wgrant> qastaging updates every half an hour, but takes >50 minutes to finish.
[04:41] <lifeless> mmm
[04:41] <lifeless> I'm sure its higher freq than that
[04:42] <lifeless> so bb is 4 hours
[04:42] <lifeless> and ec2 doesn't count as 'after landing' time
[04:42] <lifeless> latency for qa staging is ~5 hours IIRC
[04:43] <wgrant> EC2 has to be included in the equation.
[04:43] <lifeless> Anyhow, I'm aiming, as I said, at 4 hours from 'committed to live'
[04:43] <wgrant> Right.
[04:43] <wgrant> That will be excellent.
[04:43] <lifeless> in a developer box
[04:43] <wgrant> And may fix the QA issues.
[04:44] <lifeless> I don't think its necessary to fix the qa isues
[04:44] <lifeless> it may allow more slack without pathologies turning up
[04:46] <lifeless> the basic problem is 'done done' in kanban, and I'll be writing about that in a fortnight
[04:47] <lifeless> [04:47] <lifeless>     Hard / Soft  Page ID
[04:47] <lifeless>       44 /  180  BugTask:+index
[04:47] <lifeless>       24 /  225  Distribution:+bugs
[04:47] <lifeless>       21 / 3328  Archive:+index
[04:47] <lifeless>       15 /    5  Archive:+copy-packages
[04:47] <lifeless>       12 /  112  ProjectGroupSet:CollectionResource:#project_groups
[04:47] <lifeless>        9 /    3  ProjectGroup:+milestones
[04:47] <lifeless>        8 /   42  MailingListApplication:MailingListAPIView
[04:47] <lifeless>        8 /   28  Distribution:+addquestion
[04:47] <lifeless>        8 /   21  DistroArchSeries:+index
[04:47] <lifeless>        6 /    5  NullBugTask:+index
[04:47] <wgrant> poolie: answers.launchpad.net/launchpadlib isn't deliberately disabled.
[04:48] <wgrant> poolie: It just needs someone to toggle the answers flag on (that flag has only been respected for a few weeks).
[04:52] <LPCIBot> Project devel build (328): FAILURE in 3 hr 8 min: https://hudson.wedontsleep.org/job/devel/328/
[04:52] <LPCIBot> * Launchpad Patch Queue Manager: [r=sinzui][ui=none][bug=683748] Replaces launchpadlib_for_anonymous
[04:52] <LPCIBot> with an extension of launchpadlib_for
[04:52] <LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=136870][bug=674546][bug=674546][bug=202136][bug=297531]
[04:52] <LPCIBot> Fixed 'nominate for a series' text. and text in links and emails
[04:52] <LPCIBot> * Launchpad Patch Queue Manager: [r=deryck][ui=none][bug=672619] Expose bug subscription filters via
[04:52] <LPCIBot> the web service API.
[04:53] <wgrant> StevenK: Hudson has filled up again :(
[05:06] <LPCIBot> Project db-devel build (243): STILL FAILING in 3 hr 16 min: https://hudson.wedontsleep.org/job/db-devel/243/
[05:06] <LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12128,
[05:06] <LPCIBot> 12129 included.
[05:06] <LPCIBot> * Launchpad Patch Queue Manager: [r=stub,thumper][ui=none][bug=45270] lucilleconfig is gone.
[05:06] <LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12121,
[05:06] <LPCIBot> 12122, 12123, 12124, 12125, 12126, 12127 included.
[05:19] <StevenK> It has?
[05:20] <StevenK> /dev/xvda              16G  4.2G   11G  29% /
[05:20] <stub> lifeless: http://paste.ubuntu.com/546482/
[05:20] <wgrant> StevenK: At least the devel slave has.
[05:20] <stub> lifeless: look familiar? Looks like the all (?) the remaining failures are launchpad vs. launchpad.dev
[05:20] <wgrant> OSError: [Errno 28] No space left on device: '/tmp/sftp-test/branches'
[05:20] <StevenK> wgrant: Right
[05:21] <stub> lifeless: I'm assuming the tests here need to be fixed, because the port number is dynamic
[05:21] <lifeless> that (sftp-test) needs randomisation too
[05:21] <wgrant> This is a bit special.
[05:21] <lifeless> wgrant: care to file a bug asking for it and add it to the parallelisation page?
[05:21] <wgrant> Apache is currently eating 590% CPU.
[05:22] <wgrant> lifeless: Is that just a tag, or are they listed somewhere on the wiki?
[05:22] <lifeless> wgrant: there is a tag
[05:22] <lifeless> wgrant: defined on the wiki page ;)
[05:22] <wgrant> Heh, OK.
[05:22] <lifeless> stub: uhm yes
[05:22] <lifeless> stub: wallyworld landed a patch which provides expected values for this sort of thing
[05:22] <wgrant> lifeless: There are quite a few other things that need randomisation, at least in Soyuz.
[05:22] <wgrant> But it's possible as of yesterday, now that lucilleconfig is gone.
[05:23] <lifeless> stub: he posted to the list a FAQ about it, and added it to the hacking guide
[05:23] <lifeless> wgrant: \o/
[05:23] <stub> lifeless: Do we have a preferred spelling for the fix landed already somewhere? Or should I make it up?
[05:23] <lifeless> http://xkcd.com/837/# win!
[05:24] <lifeless> stub: yeah, wally's thing
[05:24] <stub> Can you be any vaguer? :-)
[05:24] <lifeless> stub: [Launchpad-dev] Recap: do not use hard coded url ports in tests
[05:24] <wgrant> lifeless: That's for librarian URLs too, not just webapp ones?
[05:24] <lifeless> thats the thread subject
[05:25] <lifeless> stub: so, this will need something analagous but not identical to what Ian did
[05:25] <lifeless> stub: make it up :)
[05:26] <lifeless> something like self.layer.librarian_download_url() or some such
[05:26] <lifeless> OTOH a doctest is terrible for this sort of thing
[05:27] <wgrant> Damn, now you're guilting me into not adding to the one I'm currently editing.
[05:40] <StevenK> Hah
[05:43] <wgrant> Do we have any UI reviewers outside the US at the moment?
[05:44] <wgrant> I am trying to think of a reasonable UI description for the Archive.publish flag.
[05:44] <lifeless> what does it do
[05:44] <StevenK> "Will this archive be processed by the publisher" ?
[05:44] <wgrant> It controls whether packages will be published to the user-visible archive disk.
[05:45] <wgrant> Right.
[05:45] <wgrant> I don't want that flag exported at all.
[05:45] <wgrant> But I cannot convince Julian of that.
[05:45] <wgrant> Maybe if I remove it he won't notice.
[05:45] <lifeless> so
[05:45] <lifeless> after building
[05:45] <lifeless> and inclusion in the librarian
[05:45] <lifeless> just the last step
[05:45] <wgrant> Right.
[05:46] <lifeless> so
[05:46] <StevenK> wgrant: Exported over the API or the UI, or both?
[05:46] <wgrant> StevenK: UI.
[05:46] <wgrant> It makes sense for copy archives.
[05:46] <lifeless> 'When disabled the APT archive for this PPA is frozen and will not receive updates.' ?
[05:46] <wgrant> But not PPAs.
[05:46]  * StevenK tries to run 'watch euca-describe-instances'
[05:47] <StevenK> Er, tries to not run ...
[05:47] <lifeless> 'Disabling this checkbox will freeze the APT archive for this PPA. No changes will be made to the archive until the checkbox is reenabled.'
[05:48] <lifeless> wgrant: ^ is that accurate?
[05:48] <wgrant> lifeless: That's accurate.
[05:48] <wgrant> But doesn't fit our usual checkbox description style.
[05:49] <wgrant> Perhaps I could prefix it with 'Update the APT archive.'
[05:49] <wgrant> That might work.
[05:49] <lifeless> southwestern-opaque ?
[05:49] <StevenK> wgrant: Periodically update the APT archive
[05:49] <lifeless> wgrant: invert the sense in the UI
[05:49] <StevenK> With correct spelling
[05:49] <lifeless> StevenK: the cron nature is irrelevant
[05:50] <lifeless> wgrant: 'Freeze the APT archive. No changes will be made to the APT archive for this PPA while the checkbox is enabled.'
[05:50] <lifeless> gets rid of the double negative
[05:51] <wgrant> I am retitling Archive.enabled to "Accept and build packages uploaded to this archive.", and Archive.publish to "Publish uploaded packages to the APT archive.".
[05:51] <wgrant> How does that sound?
[05:51] <lifeless> publishing is jargon
[05:51] <wgrant> Perhaps with an extra sentence on the second one to make the lack of updates clear.
[05:51] <lifeless> I was trying to avoid the term
[05:51] <wgrant> It is.
[05:51] <lifeless> I think that inverting the sense is appropriate here
[05:52] <wgrant> Possibly.
[05:52] <lifeless> possibly for both.
[05:52] <lifeless> but I'm less convinced about enabled.
[05:52] <wgrant> I think enabled is OK.
[05:52] <wgrant> I am inverting publish.
[05:53] <wgrant> Mm, except it would be nice to avoid the word 'freeze'.
[05:54] <wgrant> As that would be an overload.
[05:54] <lifeless> true
[05:54] <lifeless> halt
[05:54] <lifeless> 'Halt updates to the APT archive. No changes will be made to the APT archive for this PPA while the checkbox is enabled.'
[05:55] <wgrant> I can't refer to PPAs here, unfortunately. But I will work out something along those lines.
[05:55] <wgrant> Thanks.
[05:56] <lifeless> why not?
[05:56] <wgrant> Because it's IArchive, not IPPA.
[05:56] <wgrant> Copy archives are the major user of this flag.
[05:56] <lifeless> It still knows what it is
[05:56] <wgrant> This is Zope.
[05:56] <lifeless> yes
[05:56] <lifeless> it still knows what it is
[05:56] <lifeless> shove a property on the view
[05:56] <wgrant> In an attribute definition on an interface?
[05:57] <lifeless> uhhhh
[05:57] <lifeless> ok, I hates that
[05:57] <wgrant> It's an autogenerated form.
[05:57] <wgrant> It is nice, except yeah.
[05:57] <lifeless> <- unconvinced by autogenerated forms
[06:00] <shri> Hi all
[06:00] <lifeless> hi
[06:00] <shri> hi lifeless
[06:00] <wgrant> lifeless: Autogenerated widgets are just about necessary.
[06:01] <wgrant> lifeless: If your framework doesn't have them, you reimplement them quickly...
[06:01] <wgrant> But they don't need to be as inflexible as Zope's.
[06:02] <wgrant> Well then.
[06:03] <lifeless> ohbau
[06:03] <wgrant> Pardon?
[06:03] <lifeless> humour, and a typo
[06:04] <StevenK> O bai, as opposed to 'O hai' since shri said hi and then quit
[06:04] <wgrant> Ah, I see.
[06:05]  * StevenK moves on from euca-describe-instances to euca-get-console-output
[06:06] <wgrant> That broken?
[06:07] <StevenK> I've uploaded a new EMI, but firing up an instance of it hasn't started
[06:07] <wgrant>     halt_archive_updates = Bool(
[06:07] <wgrant>         title=_("Halt archive updates"), required=False,
[06:07] <wgrant>         description=_(
[06:07] <wgrant>             "Halt updates to the APT archive. Uploads and builds will "
[06:07] <wgrant>             "continue, but packages not be made available to APT until "
[06:07] <wgrant>             "updates are enabled."))
[06:07] <wgrant> lifeless: ^^ how does that look?
[06:07] <wgrant> Er, missed a word there.
[06:07] <wgrant> s/packages/packages will/
[06:08] <StevenK> That turns into a double-negative
[06:08] <StevenK> Halting is true, therefore do nothing
[06:09] <wgrant> It's what lifeless suggested.
[06:09] <wgrant> And I think it makes more sense.
[06:09] <wgrant> Since publishing is the more natural state.
[06:11] <lifeless> wgrant: great
[06:12] <lifeless> except
[06:12] <lifeless> tweak:
[06:12]  * StevenK shakes his head at the deployment report:
[06:12] <StevenK> Revision 12102 can be deployed: qa-ok
[06:12] <StevenK> Revision 12102 is bad: possible blocker.
[06:12] <wgrant> StevenK: It has two bugs linked.
[06:13] <StevenK> Ah, that bug still isn't fixed
[06:13] <wgrant> One qa-ok, one qa-i-hate-recipes.
[06:13] <lifeless> "Halt updates to the APT archive. Packages will not be made available to APT while updates are halted. While halted uploads are still possible and will be built."
[06:13] <lifeless> wgrant: something like that
[06:13] <lifeless> wgrant: I'm not sure the build/upload stuff should be mentioned
[06:14] <wgrant> lifeless: Existing packages will still be available.
[06:14] <StevenK> wgrant: Er? Both bugs are 'qa-ok' ?
[06:14] <wgrant> Only new stuff won't be.
[06:14] <lifeless> wgrant: yes, I know; I'm riffing on your text is all
[06:14] <lifeless> wgrant: I think I preferred 'no changes' as the way to communicate
[06:14] <lifeless> wgrant: but its up to you
[06:14] <wgrant> StevenK: Ah, true now. But one has bad-commit-blah
[06:16] <wgrant> lifeless: How about s/but packages will not be made available to APT/no changes will be available to APT/?
[06:16] <StevenK> Ah ha. It's fixed in r12121
[06:16] <wgrant> StevenK: Yeah.
[06:16] <poolie> wgrant: oh i see
[06:17] <wgrant> StevenK: Which is conveniently after 12111, which I rolled back in 12138
[06:17] <wgrant> So we have 12102-12137 undeployable.
[06:17]  * StevenK gets a rope
[06:18] <poolie> i don't feel i should shift it
[06:18] <wgrant> poolie: Should we just turn it on now, I wonder?
[06:18] <wgrant> Heh.
[06:18] <poolie> actually why not
[06:18] <wgrant> There are lots of questions there.
[06:18] <poolie> it's probably no worse than having people ask questions in ubuntu
[06:18] <wgrant> Right.
[06:18] <wgrant> I need to file a bug about that text.
[06:18] <wgrant> And that form.
[06:19] <StevenK> wgrant: I note 12131 is the last rev on the report
[06:20] <wgrant> StevenK: Right. 12138 won't be blessed for another 5 hours.
[06:20] <wgrant> After that I have 10 revs to QA and I may be able to get a deploy tomorrow night.
[06:20] <StevenK> But r12111 is qa-bad
[06:20] <wgrant> Right, that's the one I reverted.
[06:20] <wgrant> 12102 is fixed in 12121, 12111 is reverted in 12138
[06:20] <StevenK> Right, then r12119 is needstesting
[06:21] <wgrant> Is that the MP email one?
[06:21] <wgrant> Yes.
[06:21] <StevenK> And then r12128-r12131
[06:21] <wgrant> And 12132-12137
[06:22] <wgrant> Although most of that latter set are easy.
[06:22] <StevenK> Are they your death-to-lucilleconfig changes?
[06:23] <wgrant> No.
[06:23] <wgrant> They landed days ago, except for the db-devel change.
[06:23] <wgrant> They are little UI tweaks.
[06:25] <wgrant> Now to fight with the Zope form machinery. :(
[06:25]  * StevenK grumbles at UEC
[06:25] <wgrant> What's it doing?
[06:25] <StevenK> Nothing, which is the problem
[06:26] <wgrant> Yay.
[06:26] <StevenK> steven@hudson:~$ euca-get-console-output i-4CB608E7 | tail -n 2
[06:26] <StevenK> init: plymouth-splash main process (362) terminated with status 2
[06:26] <wgrant> Hm, nice.
[06:26] <StevenK> A sucessful boot of a different EMI also includes that line
[06:26] <wgrant> :(
[06:37] <lifeless> wgrant: my brain fails at 'no changes will be available to APT'
[06:37] <lifeless> wgrant: I think the thing here is that APT reads an archive.
[06:37] <lifeless> you can sayd 'the archive is not changed'
[06:38] <lifeless> you cannot say 'APT receives changes'
[06:38] <wgrant> The issue is that there are two archives.
[06:38] <lifeless> *I* would talk about *changes to the archive* - because thats what it controls.
[06:38] <wgrant> The one in LP.
[06:38] <wgrant> And the one that apt sees.
[06:38] <lifeless> wgrant: Thats why I said 'APT archive'
[06:38] <lifeless> in my proposals
[06:38] <wgrant> Right.
[06:38] <wgrant> But I don't reallly want to say that twice.
[06:50] <wgrant> Now I remember why I don't like LP UI work.
[06:50] <wgrant> We don't really have standards, so my pedantry fails.
[07:13] <lifeless> well
[07:14] <lifeless> there are multiple dimensions here
[07:14] <lifeless> I'm being pedantic on clarity
[07:14] <wgrant> Right. And we can't have guidelines for that.
[07:14] <lifeless> avoiding saying APT archive twice seems silly, to me, if repeating it is clearer.
[07:14] <wgrant> At the moment I'm trying to clean up all the PPA forms.
[07:14] <lifeless> cool
[07:15] <wgrant> But I am being foiled by the lack of definition of form UI guidelines. Are field captions title or sentence case? Should their descriptions refer to "the archive" or "this archive"? ...
[07:15] <wgrant> We have both throughout the app.
[07:15] <wgrant> And it looks pretty scrappy :/
[07:16] <wgrant> It's not that hard to make it look fantastic. I think we just need to sit down and define guidelines, preferably with a UI designer which we don't have.
[07:19] <lifeless> uhm
[07:19] <lifeless> ask mpt :)
[07:19] <wgrant> Hm? What's he now?
[07:22] <lifeless> interaction designer
[07:22] <lifeless> he's still interested in lp
[07:22] <lifeless> and we don't need authoritar, we just need someone we knowledge and reasoning skills in that domain
[07:23] <wgrant> Hence only "preferably"
[07:23] <wgrant> If we had one, they would probably be such a person.
[07:24] <wgrant> Oh, mpt is even coming to the epic. Excellent.
[07:24] <lifeless> why wait? ask today
[07:25] <wgrant> Then I will have a couple of issues resolved and much less inclination to actually solve everything in January.
[07:26] <lifeless> sounds like progress to me
[07:26] <lifeless> do you know what your squad will be allocated to yet?
[07:26] <wgrant> No.
[07:26] <wgrant> Has that been determined?
[07:27] <lifeless> some bits I'm sure of
[07:27] <lifeless> the 2 project squads will be taking the oldest live projects and running with them from the stakeholder queue ( I don't remember what they are - privacy is one, I think. IMBW)
[07:27] <lifeless> blah
[07:27] <lifeless> 3 project squads
[07:27] <lifeless> and the 2 interrupt squad duties are fairly well defined
[07:28] <lifeless> I don't know if the initial allocation to interrupt/project is done yet or not
[08:04] <LPCIBot> Project devel build (329): STILL FAILING in 3 hr 11 min: https://hudson.wedontsleep.org/job/devel/329/
[08:04] <LPCIBot> * Launchpad Patch Queue Manager: [rs=wgrant][ui=none][rollback=12111] Revert devel r12111. It breaks
[08:04] <LPCIBot> recipe creation for source package branches.
[08:04] <LPCIBot> * Launchpad Patch Queue Manager: [r=jcsackett,
[08:04] <LPCIBot> sinzui][ui=sinzui][bug=526608] Ajaxify plus sign next to ajaxified
[08:04] <LPCIBot> link for targeting a bugtask to a milestone.
[08:04] <LPCIBot> * Launchpad Patch Queue Manager: [r=bac][ui=none][bug=321675] Changes the 'Delete' button when
[08:04] <LPCIBot> unlinking a bug and a branch to "Remove link"
[08:04] <LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=135009, 135012, 135015,
[08:04] <LPCIBot> 135018] Adds autofocus to several fields needing it throughout
[08:04] <LPCIBot> Launchpad
[08:25] <LPCIBot> Project db-devel build (244): STILL FAILING in 3 hr 18 min: https://hudson.wedontsleep.org/job/db-devel/244/
[08:25] <LPCIBot> Launchpad Patch Queue Manager: [testfix][rs=thumper] Fix the FakeLogger import.
[08:28] <stub> What is the silly name of that test results viewer again?
[08:28] <wgrant> tribunal?
[08:30] <stub> thats the onbe
[08:44] <stub> lifeless: of course, with the restricted URL stuff we have no choice but to invoke client.getURLForAlias, which makes a number of the tests in librarian.txt somewhat redundant...
[09:46] <jml> one hundred!
[09:47] <wgrant> It was 101 earlier :(
[09:48] <jml> bugs get reopened, I guess.
[09:48] <jml> or my script is buggy
[09:49] <wgrant> jml: You made it home?
[09:49] <jml> wgrant: indeed I did. I'm in my London home right now.
[09:51] <jml> wgrant: also, welcome to the cabal. I trust you've received your codex and binding ring, and have been taught the seven words.
[09:52] <wgrant> jml: Indeed, all those formalities are complete.
[09:52] <jml> wgrant: glad to hear it :)
[09:54] <wgrant> I think victory may be near.
[09:56] <jml> wgrant: oh?
[09:58] <wgrant> jml: There may yet be hope for deploying the fix for bug #692114 before next year.
[09:58] <_mup_> Bug #692114: Recipe builds require indices for non-main PPA components <qa-ok> <recipe> <Launchpad itself:Fix Committed by wgrant> < https://launchpad.net/bugs/692114 >
[09:59] <jml> wgrant: heh
[09:59] <pcjc2> gmb: Thanks for merging that branch ;)
[09:59] <jml> I'd been meaning to ask what our deployment options were. We're still able to do non-downtime ones, right?
[09:59] <wgrant> jml: It was discovered on Saturday and the fix and test took less than two minutes... but deployment is problematic because of a chain of qa-bad revisions.
[10:00] <jml> :(
[10:00] <wgrant> In the window between a qa-bad revision and its reversion, another qa-bad revision can spring up :(
[10:00] <pcjc2> https://bugs.launchpad.net/launchpad/+bug/692951 shows fix committed - how long before its on production machines? (e.g. staging?) so I can get some test bug imports done?
[10:00] <_mup_> Bug #692951: Don't show <empty comment> placeholders for imported bug attachments <qa-needstesting> <Launchpad itself:Fix Committed by pcjc2> < https://launchpad.net/bugs/692951 >
[10:00] <wgrant> pcjc2: It could be on staging now.
[10:01] <wgrant> Let me check.
[10:01] <pcjc2> still qa-needstesting
[10:01] <wgrant> staging is not production. It updates automatically, regardless of QA.
[10:01] <wgrant> It is used for QA.
[10:01] <pcjc2> ok, excellent..
[10:01] <pcjc2> Who should I ask nicely to do a couple of imports for me?
[10:01] <wgrant> pcjc2: Staging has the fix.
[10:02] <pcjc2> And it runs a clone / snapshot of the normal production database?
[10:02] <pcjc2> seems our projects are present
[10:03] <wgrant> We can probably go directly to a LOSA.
[10:03] <wgrant> Right, it runs an old snapshot of the production DB.
[10:06] <pcjc2> Have two xml files here.. 6.1M and 9.8M
[10:09] <pcjc2> pre-validated on a local dev instance of course ;) - Although the gEDA one has two failures, which I'm happy with -  if preferred, I could just edit out those bugs
[10:11] <wgrant> pcjc2: Do they have empty comments?
[10:12] <wgrant> Oh, of course, that's why you wanted staging updated.
[10:12]  * wgrant headdesks.
[10:12] <wgrant> Excellent.
[10:12] <pcjc2> some did
[10:12] <wgrant> So it can double as QA for the bugfix.
[10:12] <pcjc2> The only one which failed (and an identical duplicate) was one where someone pasted an entire build log for a program into the bug description
[10:12] <pcjc2> Nice
[10:13] <pcjc2> As it happens, it was filed against the wrong project, so got promptly closed. Hence - I don't care they are dropped with a validate error by the import script. (Validate error is because the description is too long)
[10:14] <wgrant> Ah, right.
[10:15] <pcjc2> I can find the empty comment ones. Actually.. none have a truly empty comment.. the ones in question had attachments - so the lack of an  "<empty comment>" appended is a QA of the patch having its desired effect
[10:15] <pcjc2> We can probably run some dummy imports with actually empty comments if you like..
[10:19] <jml> I'm afk for a bit to get coffee etc.
[10:30] <wgrant> pcjc2: Where are those two files?
[10:31] <pcjc2> not uploaded anywhere at the moment.. too big to email, and I don't have any web space I can get at with quota left!
[10:31] <pcjc2> Is there somewhere temporary I can stick them on LP?
[10:31] <wgrant> They're not *that* big.
[10:32] <wgrant> Uh, good question.
[10:33] <pcjc2> I found some space.. give me a minute
[10:33] <wgrant> Great.
[10:37] <pcjc2> also - if I gzipped them, they would probably end up tiny... but I have the space now. (Obviously too tired today)
[10:37] <wgrant> Heh.
[10:38] <pcjc2> http://www2.eng.cam.ac.uk/~pcjc2/geda_output_v1.xml
[10:38] <pcjc2> to import against "-p geda"
[10:38] <pcjc2> http://www2.eng.cam.ac.uk/~pcjc2/pcb_output_v2.xml
[10:38] <pcjc2> to import against "-p pcb"
[10:39] <pcjc2> My quota on that system (with the webspace) is only 512M, including all cache-files, work etc..
[11:02] <allenap> 100 bugs closed so far \o/ http://mumak.net/lp-bugjam-2010/
[11:03] <pcjc2> wgrant: I see the gEDA ones are importing nicely / have been imported (can't remember our total count)
[11:03] <pcjc2> Same as my local tests though.. they are all marked with full bug heat.. any idea why?
[11:04] <wgrant> pcjc2: Let me have a look.
[11:04] <wgrant> It may be that the import script doesn't change the cached max heat value on the project.
[11:05] <pcjc2> so it will auto-update at some point?
[11:09] <wgrant> pcjc2: I guess they probably all have identical heat values.
[11:09] <wgrant> Because they probably only have one subscriber each.
[11:09] <wgrant> And none of the other heat factors apply.
[11:09] <pcjc2> ah, ok
[11:10] <wgrant> Do you know of a bug where we can check the empty comment behaviour?
[11:13] <wgrant> pcjc2: I just subscribed to a pcb bug to see if the heat calculation was working, and it seems to be.
[11:13] <wgrant> All except that bug now have just three flames.
[11:13] <pcjc2> ok, great. We just need to do a little triage I guess
[11:14] <wgrant> Heat is deliberately not very affected by triage.
[11:14] <wgrant> You can see the metrics involved by clicking on the flames on the bug page.
[11:14] <pcjc2> I meant by subscribing appropriate developers really
[11:14] <pcjc2> or getting people to rate the bug with "affects me"
[11:15] <pcjc2> Bug has not been active* in within the past 24 hoursSubtract 1% of the bug heat score for every day of inactivity
[11:16] <pcjc2> obviously this is calculated iteratively?
[11:16] <pcjc2> otherwise all our historical bugs would have low bug heat I guess
[11:18] <pcjc2> no.. no, it does things the sensible way... total_heat = int(total_heat * (0.99 ** days_since_last_update))
[11:19] <pcjc2> although I wonder if it is looking at the date of import as the last update date
[11:20] <wgrant> Yeah, it probably is.
[11:20] <wgrant> That's slightly unfortunate.
[11:21] <wgrant> pcjc2: Which bugs had the empty comments?
[11:21] <pcjc2> almost anything with an attachment _previously_ would import with "<empty comment>"
[11:21] <pcjc2> let me find an example
[11:21] <wgrant> Both imports are done now.
[11:22] <pcjc2> ;)
[11:23] <pcjc2> net connection is a bit flaky here
[11:23] <pcjc2> https://bugs.staging.launchpad.net/pcb/+bug/692470
[11:24] <pcjc2> If you had access to an instance _not_ running the fix
[11:24] <pcjc2> you would see it imports with <empty comment> for each of those attachments
[11:24] <wgrant> Yep, I've seen that before.
[11:24] <wgrant> That is a lot of attachments.
[11:24] <wgrant> Looks good, thanks.
[11:26] <pcjc2> I added a unit test which checks the old behaviour for a truly empty comment
[11:26] <pcjc2> How much (if any) extra QA is required?
[11:27] <wgrant> I marked the bug qa-ok a couple of minutes back.
[11:27] <wgrant> It all looks good to me.
[11:29] <pcjc2> nice, thanks!
[11:29] <pcjc2> How long until it hits production?
[11:30] <wgrant> I'm just working out how to QA the last couple of items.
[11:32] <wgrant> Then we can hopefully deploy as soon as that's done.
[11:41] <pcjc2> cool. I've sent an email to the gEDA lists requesting people take a look at things and get back to me with our own QA on the bug import
[11:46] <pcjc2> I've found some breakage already.. https://sourceforge.net/tracker/?func=detail&aid=2922765&group_id=73743&atid=538811  ->   https://bugs.staging.launchpad.net/pcb/+bug/692282
[11:46] <_mup_> Bug #692282: package nspluginwrapper 1.2.2-0ubuntu6.9.10.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 135 <amd64> <apport-package> <nspluginwrapper (Ubuntu):New> < https://launchpad.net/bugs/692282 >
[11:46] <pcjc2> &#226;&#8364;&#732;elementColor (color)&#226;&#8364;&#8482;
[11:46] <wgrant> Ahhh XML, I love you so.
[11:46] <pcjc2> probably just need to grep for failure like that and convert in my script
[11:47] <pcjc2> The line I just pasted was the SF export XML. It got munged by the time it got to output.xml
[11:47] <pcjc2> â€˜elementSelectedColor (color)â€™
[11:47] <wgrant> Fun.
[11:47] <pcjc2> So LP is not to blame.. just the export script I think
[11:48] <pcjc2> I've got a pile of changes / extensions / fixes to return for that already
[11:48] <pcjc2> @ _mup_: Naugty bot.. learn to notice which server I'm talking about ;)
[11:49] <pcjc2> got to head out for a bit.. back later
[11:50] <wgrant> allenap: Are you going to be able to QA that structural subscriptions API thing? Although I did the initial export of that part of the code, I don't know the new stuff, so I'm not entirely comfortable that I can QA it adequately.
[11:51] <allenap> wgrant: I'm trying to QA it at the moment. It seems to work okay, but I want to check if the bug mail was sent correctly. BTW, what do you mean by "initial export of that part of the code"?
[11:53] <wgrant> allenap: Oh, I thought it was structural subscriptions. It looks like I was mistaken.
[11:54] <allenap> wgrant: It is structural subscriptions: bug filters for structural subscriptions. The Debian BTS stuff is unrelated.
[11:58] <LPCIBot> Project db-devel build (245): STILL FAILING in 3 hr 33 min: https://hudson.wedontsleep.org/job/db-devel/245/
[12:07] <deryck> Morning, all.
[12:07] <jml> good morning deryck
[12:07] <wgrant> Morning deryck.
[12:10] <jml> deryck: how goes the per-package dupe disabling thingy?
[12:10] <deryck> jml: 'tis done.  I sent email to the stakeholders on the LEP for feedback, they're happy, but I never followed up on the stakeholders list that it was done.
[12:11] <jml> deryck: ahh cool.
[12:11]  * jml updates the board
[12:11] <deryck> jml: JFo is still concerned that they will need per package ability to turn off 'mark as duplicate' link except for bug supervisor, so I'm gathering data to see if that is really a widespread issue or not.
[12:12] <jml> deryck: fair enough.
[13:24] <Ursinha> hey jelmer, you're a soyuz guy, right?
[13:24] <jelmer> Ursinha: Yep!
[13:27] <Ursinha> cool :)
[13:28] <Ursinha> jelmer, I'm seen lots and lots of oopses in the soyuz report, like this one: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1812PPA1221
[13:28] <Ursinha> do you know what's this?
[13:28] <Ursinha> I've seen
[13:28] <wgrant> Ugh, yes, I really should fix that.
[13:28] <jelmer> That's the new apache access log parser
[13:28] <wgrant> They are ignorable.
[13:28] <Ursinha> ah, right
[13:30] <jelmer> oh, wgrant's still up :-)
[13:31] <wgrant> Barely.
[14:07] <henninge> danilo_, danilos: which one are you? ;)
[14:08] <danilo_> henninge, make your pick (uhm, only this one)
[14:08] <henninge> danilo_: Do you remeber trying to fix bug 401618?
[14:08] <_mup_> Bug #401618: Remove [I]POTMsgSet.sequence <lp-translations> <message-sharing> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/401618 >
[14:08] <henninge> danilo_: Did you give up on the stepthrough approach?
[14:09] <danilo_> henninge, I am pretty sure we gave up on it with the idea that we'll get new +translate page and underlying structures
[14:10] <henninge> ;)
[14:10] <henninge> *that* is too much for a bug jam ...
[14:10] <danilo_> henninge, yes, it is :)
[14:11] <henninge> danilo_: how did you think to use stepthrough here? I think it would mean changing URLs for translation messages.
[14:12] <danilo_> henninge, it means having a stepthrough method implementation which goes through parent (pofile) to get the right sequence number
[14:13] <danilo_> henninge, we definitely shouldn't change the URLs though
[14:13] <danilo_> henninge, iow, this doesn't qualify as a good candidate for the bugjam consider we are not certain what needs to be done
[14:13] <henninge> danilo_: yes, but stepthrough takes a constant string (like "+tm") and we don't have that here.
[14:13] <henninge> yes, I agree.
[14:14]  * henninge looks for more places to remove cruft
[14:14] <pcjc2> What does the "tech-debt" tag mean?
[14:14] <henninge> maybe continue on the product-to-project quest?
[14:15] <danilo_> henninge, if that's easy enough
[14:15] <henninge> pcjc2: technical debt is stuff we coded badly for time reason and promised to fix later ...
[14:15] <henninge> boy, are we in debt .... ;)
[14:16] <pcjc2> ah, cool. Wondered if it was pay-back tasks for people who'd had tech-training from Canonical or something ;)
[14:16] <henninge> interesting idea ... ;)
[14:17] <pcjc2> Most of my code could be considered tech-debt! I'm wading through a 40+ commit patch series which re-writes a CAD packages rendering stack in OpenGL
[14:17] <pcjc2> Not fun
[14:17] <pcjc2> Not fun when "it works", but I can't bear to commit it as is. (This is about the 3rd refactor / re-write though!)
[14:22] <danilo_> henninge, btw, you can always directly implement traverse()
[14:23] <danilo_> pcjc2, the joy of free software is getting over the hump of embarrasment: code that works and is ugly is usually of bigger value than no code at all :) of course, with long-living projects, you do have to worry about maintainability as well
[14:24] <pcjc2> Since I'm usually the one playing big-bad grumpy patch reviewer, I need to make clean commits
[14:24] <pcjc2> Code is all published and people use it.. its just not "upstream" yet
[14:24] <danilo_> pcjc2, multiple branches help with that: non-clean branch that implements this cool feature and a master that is eager to get that feature will push you to get it cleaned up while letting people get at the feature if they really want to :)
[14:25] <danilo_> pcjc2, there you go, same thoughts then :)
[14:25] <pcjc2> indeed
[14:26] <pcjc2> I have ~8 branches here for the circuit board CAD (PCB), ~8 for the schematic CAD (gEDA)
[14:27] <pcjc2> Upstream is mostly just me and a couple of other active guys. (~1 per project) Things have become a little stagnant in terms of new development
[15:15] <LPCIBot> Project db-devel build (246): STILL FAILING in 3 hr 14 min: https://hudson.wedontsleep.org/job/db-devel/246/
[15:15] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12137,
[15:15] <LPCIBot> 12138 included.
[16:20] <james_w> rockstar, hey, I was going to fix bug 666979 if you could help me decide on the best solution
[16:20] <_mup_> Bug #666979: soupmatchers.Tag takes a text argument that should ignore whitespace <soupmatchers:New> < https://launchpad.net/bugs/666979 >
[20:58] <jml> thumper: you around today?
[21:18] <thumper> jml: no
[21:18] <jml> thumper: thanks. enjoy your holiday.
[23:01] <jcsackett> lifeless ping
[23:15] <jcsackett> nm.
[23:21] <lifeless> sinzui: if you know what jc wanted, let me know? :)