[00:16] <wgrant> lifeless: I'm pretty sure that 566339 is not fixed by the branch in question.
[00:17] <wgrant> And 564491 needs somebody to drive DF.
[00:17] <lifeless> wgrant: is it made worse?
[00:17] <wgrant> No.
[00:17] <wgrant> Just not fixed.
[00:17] <lifeless> so remove qa-needstesting from it
[00:17] <lifeless> for the other can you arrange that with StevenK ?
[00:17] <wgrant> True.
[00:17] <wgrant> Well, can somebody else remove qa-needstesting? It's not my bug, and I'm not really Soyuz, so I don't really want to screw with their QA :)
[00:18] <lifeless> revno: 11556 [merge]
[00:18] <lifeless>   [r=stevenk, thumper][ui=none][bug=564491,
[00:18] <lifeless>         566339] Fix an OOPS when an archive admin uses the +queue page to
[00:18] <lifeless>         accept uploads that close private bugs.
[00:18] <lifeless> its qa-needs testing because of that landing
[00:18] <wgrant> It is, yes.
[00:18] <lifeless> oh, bigj
[00:18] <wgrant> bigjools thinks it fixes it, but I'm pretty sure it's irrelevant.
[00:18] <lifeless> sorry
[00:19] <lifeless> you only filed it ;)
[00:19] <wgrant> Yep.
[00:27] <wgrant> sinzui: What's the UI for pages like +configure-translations going to look like?
[00:27] <sinzui> a lot like bugs and answer
[00:27] <sinzui> oh
[00:28] <wgrant> Because the current one that almost made it out to production is very confusing :(
[00:28] <lifeless> wgrant: what rev?
[00:28] <wgrant> lifeless: The one I mentioned yesterday. r11552
[00:29] <wgrant> So not in your initial set.
[00:29] <lifeless> wgrant: it is in the second set
[00:29] <lifeless> Revision 11547 can be deployed: qa-ok
[00:29] <lifeless> Revision 11548 can be deployed: qa-ok
[00:29] <lifeless> Revision 11549 can be deployed: qa-ok
[00:29] <lifeless> Revision 11550 can be deployed: qa-ok
[00:29] <lifeless> Revision 11551 can be deployed: qa-ok
[00:29] <lifeless> Revision 11552 can be deployed: qa-ok
[00:29] <lifeless> Revision 11553 can be deployed: qa-ok
[00:29] <lifeless> Revision 11554 can be deployed: qa-ok
[00:29] <lifeless> Revision 11555 can be deployed: qa-ok
[00:29] <lifeless> Revision 11556 can not be deployed: not-ok
[00:29] <wgrant> This is what I was worried about.
[00:30]  * wgrant wonders why it isn't FF'd out.
[00:30] <lifeless> wgrant: I explicitly asked about it
[00:30] <lifeless> wgrant: and sinzui believes its an improvement even though not perfect
[00:31] <sinzui> wgrant, the registry team is only worked on the unknown, not-applicable, launchpad enum. The translations team can consider doing a unified page that does everything in one view like bugs
[00:33] <wgrant> sinzui: IMO the current translations/answers UI is a regression.
[00:33] <wgrant> What does it even mean?
[00:34] <wgrant> I don't know -- how will users?
[00:34] <lifeless> wgrant: wgrant huh
[00:34] <lifeless> wgrant: sample url? I don't recall it being confusing
[00:34] <wgrant> lifeless: https://edge.launchpad.net/launchpad/+configure-translations
[00:34] <sinzui> wgrant,  I do not think so. consistent UI  is better, being clear about what is being used or where something can be found is better.
[00:35] <wgrant> sinzui: Why not FF it out for a couple more weeks, until the new pages are built?
[00:35] <wgrant> And not roll out a half-finished awesome feature?
[00:35] <wgrant> Awesome features are much better when people don't see broken implementations first.
[00:35] <sinzui> wgrant, I do not understand. My entire team is working on this and we need edge feed back there are only a few things left to be done
[00:36] <sinzui> I think there is plenty of time to complete this
[00:36] <wgrant> sinzui: edge is fine.
[00:36] <wgrant> I don't think lpnet is the best idea yet.
[00:36] <sinzui> god knows spending a year on a so-called 6 month vision has burned me out
[00:36] <wgrant> Heh.
[00:38] <sinzui> My only regret is that I still think the DSP page is near useless and I want to be able to state where external questions and FAQs can be found
[00:38] <wgrant> We need to work out a strategy for linking them better to projects.
[00:39] <wgrant> Particularly since there are a lot of Canonical projects now that only want to use one bug tracker.
[00:43] <lifeless> s/Canonical/Ubuntu ?
[00:43] <wgrant> lifeless: Sometimes.
[00:44] <wgrant> But if you categorise Ubuntu One as Ubuntu, I will not be amused :)
[00:46] <lifeless> u1's ubuntu-only components are open source
[00:46] <mars> lifeless, mind if I bug you with a question about bug 598289?
[00:46] <lifeless> I think *if* a healthy set of packages in say fedora nd suse were to spring up, that they would see the need for 2 trackers for those components.
[00:46] <lifeless> mars: shoot
[00:46] <mars> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/598289
[00:47] <wgrant> lifeless: They're not Ubuntu-only, but OK.
[00:47] <lifeless> wgrant: the developers are only targeting ubuntu today;
[00:47] <lifeless> unless something radical has changed
[00:48] <wgrant> Yes, but there's no reason they can't run elsewhere. Like Software Center, and other stuff like that.
[00:48] <mars> lifeless, So the question was: is it safe to use feature flags to protect access to profile generation.  The answer was... yes, I think?  zope-funcertainty
[00:48] <mars> lack of zope-fu leads to zope-funcertainty
[00:49] <lifeless> wgrant: thats true; the question is whether upstream get bug reports that aren't relevant to Ubuntu
[00:49] <lifeless> wgrant: and until they are geting patches and so forth routinely, the broad answer is going to be 'no'.
[00:49] <wgrant> True.
[00:49] <lifeless> wgrant: which is why I talked about healthy packages in other distros
[00:49] <lifeless> mars: certainly
[00:50] <lifeless> mars: you'll need two patches.
[00:50] <lifeless> mars: one patch to add a team membership scope
[00:50] <lifeless> see rev 11536 for a very similar scope definition that does team membership scoping
[00:51] <lifeless> bah
[00:51] <lifeless> that does pageid scoping
[00:51] <lifeless> and please add it to https://dev.launchpad.net/LEP/FeatureFlags at the bottom
[00:51] <lifeless> mars: or fix the self-documenting bit
[00:52] <lifeless> because team lookup is a db thing, we probably want a note that using that scope will trigger team membership checks, so we don't go overboard on it.
[00:53] <lifeless> mars: secondly, you need a patch to force 'permit_profiling' or whatver it is on via a feature flag
[00:53] <lifeless> mars: see e.g. the memcache feature flag patch for an example of what that might look like
[00:53] <lifeless> these two patches are entirely unrelated to each other
[00:53] <lifeless> but together much power can be had
[00:54] <wgrant> If you don't want to hit the DB, you could use the pre-populated developer flag in ILaunchBag.
[00:55] <wgrant> That's populated for every request.
[00:55] <lifeless> thats true
[00:55] <lifeless> we could have team:<name> and special case well known names.
[00:55] <wgrant> You could.
[00:55] <lifeless> but
[00:55] <lifeless> that shouldn't be needed if its populated sanely we'll get cache hits..
[00:56] <lifeless> you could also have a flag called user_is_developer
[00:56] <lifeless> which is less general but fits the actual intent here a little more closely.
[00:56] <lifeless> I'm easy.
[00:56] <lifeless> bah
[00:56] <lifeless> not flag
[00:56] <lifeless> *scope* called user_is_developer
[00:57] <lifeless> mars: I'd add the flag ('permit_profiling') or whatever name you choose, first.
[00:57] <lifeless> mars: because onces thats added sysadmins can turn profiling on and off on staging without restarting it
[00:57] <mars> cool
[00:58] <mars> this is why I like pre-implementation calls :)
[00:58] <lifeless> I think flag are still misunderstood
[00:58] <mars> how so?
[00:58] <mars> and what is the 'fix the self-documenting' bit?
[00:59] <lifeless> (third discussion I've had today showing the difference between scopes/flags and how it hangs together.
[00:59] <wgrant> Does the infrastructure support scope conjunction?
[00:59] <lifeless> mars: no
[00:59] <lifeless> for a given flag, the rules are evaluated in priority order
[01:00] <lifeless> mars: self documenting: we should be able to query the code to find out what scopes(including pageid: magic ones) and flags (like memcache, gmaps2 etc) exist
[01:00] <lifeless> this would let us:
[01:00] <lifeless>  - display that as help in the fictional editing UI
[01:00] <lifeless>  - not have a redundant list in the wiki page
[01:01] <mars> find -iname '*py' -print0 | xargs -n0 grep getFeatureFlag | sort -u
[01:03] <lifeless> mars: you'll miss all the page template ones
[01:03] <mars> TAL flag isn't mentioned in the LEP
[01:03] <mars> only in the listmail
[01:04] <lifeless> I'm not sure there are ones deployed in tal yet, but there probably are and we should have some way of documenting them
[01:04] <lifeless> mars: find might be the answer
[01:04] <mars> find -iname '*py' -o -iname '*pt' -print0 | xargs -n0 grep -e 'getFeatureFlag' -e 'features/' | sort -u
[01:04] <mars> yuck
[01:04] <mars> do two find calls
[01:05] <mars> add a 'make doc' target
[01:05] <mars> and do the work in there
[01:05] <lifeless> mars: what might be nice is a makefile rule to do it
[01:05] <mars> along with the API docs
[01:05] <lifeless> I'd like something out that the admin UI can include and show
[01:06] <lifeless> mars: in templates getFeatureFlag isn't it
[01:06] <lifeless> its view/flags/flagname
[01:06] <lifeless> I think
[01:06] <mars> <div tal:condition="features/show_message">hello world!"</div>
[01:06] <lifeless> ah yes
[01:06] <lifeless> thats it
[01:07] <mars> lifeless, so, the difference between flags and scopes: a flag only applies in-scope I assume?  Sounds like a scope is a flag to turn on and of a set of flags
[01:07] <mars> or override a flag
[01:08] <wgrant> lifeless: Can I see OOPS-1721K2125?
[01:08] <mars> so you could have feature:X scope:default :off
[01:09] <mars> and feature:X scope:server.edge :on
[01:09] <mars> Which saves you from having to write:
[01:10] <mars> if feature:X and feature:server.lpnet then :on
[01:10] <mars> err
[01:10] <mars> if feature:X and feature:server.lpnet then ...
[01:11] <mars> which is messy.  You have to change the code if either of those two assumptions needs to change.
[01:13] <lifeless> mars: code is controlled by flags
[01:14] <lifeless> the value of a flag is determined by the highest priority rule with a matching scope
[01:14] <lifeless> rules are a tuple (scope, flag, value) sorted by priority
[01:20] <lifeless> mars: so yes, you have the point
[01:20] <lifeless> we define a name for condition we want to control
[01:20] <lifeless> and use rules to dynamically implement the particular flow control we want
[01:25] <mars> \o/ I get yet another opportunity to use the awesome bzr pipeline plugin
[01:26] <lifeless> mars: for this?
[01:26] <mars> lifeless, three patches, so yes
[01:26] <lifeless> mars: personally I wouldn't, they are totally separate patches
[01:26] <mars> flag, scope
[01:27] <lifeless> mars: unrelated
[01:27] <lifeless> mars: thats the point really ;)
[01:27] <mars> lifeless, well, you could add the flag in one patch, and not use it
[01:28] <mars> then add the scope, and use it as well
[01:28] <lifeless> mars: huh? once the flags added we can use it.
[01:28] <mars> lifeless, I must be missing something: when I write getFeatureFlag(), I have to pass in a scope, no?
[01:28] <lifeless> NO
[01:28] <lifeless> you pass in a FLAG
[01:28] <mars> so where did I get the wrong idea from...
[01:29] <mars> reading over what I read again
[01:33] <mars> Ok, so I thought I had read getFeatureFlag(flag, scope=foo) somewhere as the API.  That is wrong, and I can not find the reference.  Maybe I was confusing the "getFlag(scopes => None)" line from the LEP with the actual implementation.
[01:35] <lifeless> heh
[01:40] <mars> ok, this stuff needs a cheat sheet
[01:41] <lifeless> wgrant: that oops
[01:44] <wgrant> lifeless: That oops?
[01:45] <lifeless> ywa
[01:45] <lifeless> looks the same as the one in https://bugs.edge.launchpad.net/soyuz/+bug/276950
[01:46] <wgrant> Ah, yes.
[01:46] <wgrant> In fact it's the same OOPS.
[01:46] <wgrant> I was interested in the content.
[01:46] <wgrant> Because I don't see what is so slow.
[01:46] <wgrant> Unless it's the bad copy checker stuff.
[01:46] <lifeless> its a different oops #
[01:47] <lifeless> wgrant: the huge numbers of repeats
[01:47] <wgrant> lifeless: It's the one in comment 3.
[01:47] <lifeless> are at least 2.5 seconds
[01:47] <wgrant> Ew.
[01:47] <wgrant> Oh, there are details in the description. I see.
[01:48] <lifeless> 600 bug lookups
[01:48] <lifeless> 200 das lookups
[01:48] <lifeless> 200 archive lookups
[01:48] <wgrant> Ew.
[01:48] <lifeless> its just horribly inefficient
[01:49] <wgrant> I might be able to reproduce it locally, then.
[01:50] <lifeless> if you can't, shout
[01:50] <lifeless> the params aren't visible so I can't see what packages are being manipulated
[01:50] <lifeless> I'd guess at something stupid like all-bugs-ever-on-the-package being manipulated
[01:50] <lifeless> one at a time
[01:52] <lifeless> with an added helping of 'cache miss due to complex query results in reading what we had already' or some such
[01:53] <mars> komodo only found 5 occurrances of the string getFeatureFlag() in the devel source tree... odd.
[01:54] <lifeless> looks a little few
[01:54] <lifeless> but not far off
[01:55] <mars> Martin's mail said to "use lp.services.features.per_thread.features to look things up"
[01:55] <mars> so maybe people were doing that
[01:55] <lifeless> no
[01:55] <lifeless> because it has getFeatureFlag as the method
[01:56] <mars> hmm
[01:56] <lifeless> there are < 10 flags in use - I know of three in python code, and a couple in templates
[01:56] <mars> lifeless, which three in Python?  I can look up the exact string/symbol
[01:56] <lifeless> getFeatureFlag
[01:57] <lifeless> I documented them on https://dev.launchpad.net/LEP/FeatureFlags
[01:57] <lifeless> 11519 claims to be behind a flag...
[01:57] <mars> ah, like I said, my editor only found 5 occurrances of getFeatureFlag in the code base.  Over to grep!
[01:58] <lifeless> oh fugly
[01:58] <lifeless> folk are using FeatureController and in_scope manually.
[01:58] <lifeless> nooooo
[01:58] <mars> see?  Quickstart guides needed :)
[01:58] <mars> Looks like rf-get did the wrong thing
[01:59] <mars> and didn't update my source tree
[02:00] <mars> eh?  No - 'bzr switch -b' did something odd instead
[02:01] <lifeless> mail sent to the list
[02:02] <lifeless> ok, we need to fix up
[02:02] <lifeless> distroseries.py
[02:02] <mars> lifeless, did you work around that ec2 database issue you had earlier?
[02:02] <lifeless> mars: no, I'm assuming ec2 AMI is fucked and won'y try yo land stuff till tuesday
[02:03] <mars> ugh, sorry :(
[02:03] <lifeless> and registry/browser/__init__.py
[02:04] <lifeless> mars: possibly a postgresql dep change or something
[02:05] <mars> lifeless, should feature flags return a boolean?  Because the memcached one does "features.getFeatureFlag('memcache') != 'disabled'"
[02:06] <mars> which feels a bit strange - what other values for the flag could there be?  'maybe'?
[02:07] <lifeless> mars: they return the value
[02:07] <lifeless> mars: look up the bug for timeouts via flags
[02:07] <lifeless> I pasted a sample interpreting flag there
[02:07] <lifeless> mars: other values are useful if we wanted to (for instance) keep memcache on a couple of pages but disable it globally
[02:08] <lifeless> we'd set a priorty (say) 50 rule for (default, memcache, disabled)
[02:08] <lifeless> and add priority 0, 1, 2 etc for
[02:08] <lifeless> (pageid:pagetousememcacheon, memcache, '')
[02:09] <mars> :/
[02:11] <lifeless> mars: __nonzero__ is perfectly cromulent python
[02:11] <lifeless> as long as it doesn't have unusual consequences (like being terribly slow, or some such)
[02:12] <mars> lifeless, comparison to the string 'disabled' for a flag is a poor API imho.  featureIsEnabled('foo') => returns Boolean True or False, sounds like it would cover 99% of the cases
[02:14] <mars> with this code, bool(getFeatureFlag('memcache')) == True, even when the memcache flag's value is 'disabled'
[02:15] <mars> that's just not right
[02:15] <mars> anyway, I need to run, have to put the kids to bed. ttyl
[02:17] <lifeless> mars: ttyl
[02:17] <lifeless> mars: I think bool would be overly restrictive for no benefit
[02:17] <lifeless> mars: this is schemaless. Its a *benefit*.
[02:23] <lifeless>   Hard / Soft  Page ID
[02:23] <lifeless>      164 /  335  BugTask:+index
[02:23] <lifeless>      107 /  277  CodeImportSchedulerApplication:CodeImportSchedulerAPI
[02:23] <lifeless>       70 /   16  Distribution:+search
[02:23] <lifeless>       39 /   18  DistributionSourcePackage:+filebug
[02:23] <lifeless>       16 /    0  Product:+bugs
[02:23] <lifeless>       14 /   69  Distribution:+bugtarget-portlet-bugfilters-stats
[02:23] <lifeless>       14 /   18  DistroSeries:+queue
[02:23] <lifeless>       13 /   43  Archive:+packages
[02:23] <lifeless>       13 /    4  Archive:EntryResource:syncSource
[02:23] <lifeless>        8 /    4  Person:+rdf
[02:30] <lifeless> mars: I've tweaked the LEP
[02:30] <mars> lifeless, by schemaless, do you mean key/value pair storage?  Don't we get that already from lazr.config and from memcache?
[02:36] <lifeless> mars: lazr.config is horrific
[02:36] <lifeless> mars: and memcache is transient
[02:36] <lifeless> mars: by schemaless I mean no defined schema
[02:37] <lifeless> this is more than just keyvalue (but not a great deal more)
[02:37] <mars> lifeless, ok, put another way: is there a problem with:
[02:38] <mars> if getFeatureFlag('foo'):
[02:38] <mars>   bar = config.feature.value
[02:38] <lifeless> yes
[02:38] <lifeless> it will take hours to change.
[02:38] <lifeless> it will be static
[02:38] <mars> right
[02:39] <lifeless> we'd need a new config.feature section for every rule in the DB
[02:39] <lifeless> and rules are dynamic, so I don't see how we'd do that
[02:39] <mars> ok
[02:40] <lifeless> lazr.config is a very powerful, very complex, schemad system which pushed all integrity checking out to the setting-of-it
[02:40] <lifeless> this has the following consequence:
[02:40] <lifeless>  - its hard to use
[02:40] <lifeless>  - and complex to use.
[02:40] <lifeless> we're now, judging from what people are doing, abandoning it rapidly.
[02:41] <lifeless> I wouldn't be surprised if folk route around it completely in the next 12 months and we have a bug called 'remove the last dependencies on it'
[02:42] <mars> lifeless, so lazr.config stores data - what are they using instead?
[02:42] <lifeless> stub has added ini files
[02:42] <lifeless> poolie added feature flags
[02:43] <lifeless> stub is looking with interest at zookeepr
[02:43] <lifeless> who knows what else will turn up.
[02:44] <lifeless> lazr.config is also very intolerant, making it hard to evolve.
[02:44] <lifeless> From what I've seen of it, I'd be entirely happy to just switch to configparser now
[02:45] <lifeless> but perhaps I've missed something.
[02:45] <lifeless> (but even doing that owuldn't do what feature flags do).
[02:45] <lifeless> feature flags are: very powerful, very simple, very dynamic.
[02:46] <mars> lifeless, ok, then I would suggest a convention: 'on' or None
[02:46] <lifeless> we can do A/B testing; dynamic configuration and more
[02:46] <lifeless> mars: Why?
[02:46] <lifeless> mars: what do we gain by limiting it
[02:46] <mars> lifeless, because then bool(getFeatureFlag()) still works everywhere
[02:46] <lifeless> mars: what value does that *have*
[02:47] <mars> lifeless, bool('on') == True, bool(None) == False.  That makes sense.  The memcached flag (and it is a Bool flag right now) doesn't follow that convention.
[02:48] <lifeless> because that convention doesn't exist.
[02:48] <lifeless> And I don't see what value we'd get from it.
[02:48] <lifeless> We'd destroy the usefulness of flags.
[02:48] <mars> how?
[02:48] <lifeless> for a consistency we don't need.
[02:48] <mars> I am not saying "only use 'on' or None"
[02:48] <lifeless> mars: did you look at the bug I suggested you do, about pageid based timeout control?
[02:49] <mars> I am saying "if it is a flag, try to stick to 'on' or None
[02:49] <mars> if it is not a flag, but a keyvalue, then you're on your own :)
[02:49] <lifeless> its not a flag, its not a keyvalue
[02:51] <mars> lifeless, I saw the example you pasted in the channel, but not a bug #
[02:51] <lifeless> mars: look at launchpad-foundations bug
[02:56] <mars> found it, https://bugs.edge.launchpad.net/launchpad-foundations/+bug/627701
[03:18] <sinzui> I think my weekend plans just went tits up. Has anyone noticed that ec2 images use PG 8.3, but that our own scripts to make the environment are 8,4?
[03:19] <mars> lifeless, ^ that might explain the error you saw
[03:19]  * sinzui thinks
[03:19] <mars> did someone land a fix to the scripts to get Maverick running?
[03:20] <sinzui> I do not know I think there is just one real error in setup: /etc/init.d/postgresql: command not found
[03:20] <sinzui> I can update my branch to try 8.4 then fallback to 8.3
[03:22] <sinzui> ah, we have two script and the image does not know which one to use. This may be a one line fix
[03:23] <mars> sinzui, yep: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/11570
[03:24] <mars> sinzui, consider switching to the /usr/sbin/service utility
[03:24] <mars> then it will always do the right thing
[03:24] <sinzui> okay thanks for the advice.
[03:47] <wgrant> How will that work with version selection, though?
[04:03] <lifeless> wgrant: no idea
[04:03] <sinzui> wgrant, I see I can pass the version to service, but I do not know if service supports version in Hardy. I assume there are still some machines on Hardy
[04:04] <lifeless> we stil have dc machines on hardy
[04:04] <lifeless> but I don't know that we run any developer pg controlling scripts on them
[04:04] <sinzui> take the safe path by adding a switch between the old command and the new one
[04:07] <lifeless> james_w: http://pypi.python.org/pypi/fixtures updated
[04:22] <sinzui> wgrant, lifeless. My pg hack played on my maverick instance and in ec2. If my branch passes, we will have a fix in the tree
[04:30] <lifeless> sinzui: thanks
[04:30] <lifeless> we'll need that CP'd to production-devel
[04:30] <lifeless> by hand
[04:31] <lifeless> or is it the local content on disk when you submit that controls this?
[04:32] <wgrant> Why does production need it?
[04:33] <wgrant> Isn't production still 8.3, so EC2 should probably use 8.3 too?
[04:34] <lifeless> wgrant: we need to keep running ec2 land for prod-devel branches
[04:35] <lifeless> do you have reason to think that that isn't affected in the same way?
[04:35] <wgrant> True.
[04:38] <lifeless> one way to make sure its not affected is to run pg 8.3 and only 8.3 on it and make the dev scripts do stuff for 8.3; I don't know if thats the case.
[04:38] <lifeless> its also of minimal use because production doesn't take db patches
[04:38] <lifeless> it hatses them
[04:44] <wgrant> Although there was a bit of specialness WRT that this cycle...
[04:46] <lifeless> this is not the patch you are looking for
[05:17] <wgrant> Hm.
[05:17] <wgrant> The Django Debug Toolbar is handy.
[05:19] <lifeless> wgrant: how are you going with the +queue perf thing
[05:19] <wgrant> lifeless: Doing some uni stuff first. +queue is being attacked this evening.
[05:20] <lifeless> wgrant: K, I'll probably be around if you want to bounce ideas
[05:21] <wgrant> lifeless: I was just adding an "assuming that maverick continues to be well-behaved"... when I got my first X hang in a few months.
[05:22] <wgrant> Ahem.
[05:23] <lifeless> :)
[05:37] <wgrant> lifeless: Do you know if there's a known issue with the revision karma allocator?
[05:40] <wgrant> I've checked a few users, and nobody seems to have any in the last couple of days.
[05:40] <wgrant> Hm, there was some two days ago.
[05:40] <wgrant> So maybe it just didn't run yesterday.
[05:42] <lifeless> not aware of any incident report about it
[05:50]  * StevenK kicks Maven until pieces fall off
[08:16] <lifeless> anyone know the list that zope testing patches and plans are designed on?
[09:21] <lifeless> wgrant: https://bugs.edge.launchpad.net/soyuz/+bug/629921 -please-
[09:21] <lifeless> I'm begging you.
[09:23] <wgrant> Hmm. That was filed two weeks ago, and we are around 12000 bugs further along now... does that mean we are having 1000 filed a day!?
[09:24] <wgrant> But anyway, let's see how difficult that is...
[09:24] <wgrant> Ahh, I see.
[09:25] <wgrant> lifeless: Am I allowed to violate the no-implicit-truth guideline? That would reduce the fix to deletion of a few characters...
[09:26] <lifeless> wgrant: no implicit truth?
[09:27] <wgrant> lifeless: It's suggested not to say 'if whatever' -- instead we are told to say 'if whatever is not None'
[09:28] <wgrant> This particular case is currently 'if requested_name_filter is not None', but actually wants to be 'if requested_name_filter is not None and len(requested_name) > 0'. But 'if requested_name_filter' would work just as well.
[09:28] <lifeless> if requested_name_filter is clearer IMO
[09:28] <lifeless> doit.
[09:28] <wgrant> Excellent.
[09:29] <lifeless> given I just wrote email to the list suggesting *just that* for flags earlier today :)
[09:48]  * wgrant fixes the Maverick psycopg2 compatibility breakage.
[09:49] <lifeless> its compatible; honest.
[09:49] <wgrant> It is, but our celebrity code sucks.
[10:06] <wgrant> This does not inspire confidence:
[10:06] <wgrant>     def source_fies_dict(self, package_upload_source_dict, source_files):
[10:06] <wgrant>         """Return a dictionary of source files keyed on PackageUpload ID."""
[10:08] <wgrant> WTF
[10:08] <wgrant> WTF
[10:08] <wgrant> WTF
[10:09] <wgrant> lifeless: So... DistroSeries:+queue redirects after post.
[10:09] <wgrant> lifeless: I was looking around to see how the action handler was called.
[10:09] <wgrant> It turns out it's called by the template.
[10:09] <wgrant> After it calculates all the data to display in the event of a GET.
[10:09] <wgrant> Gar.
[10:10] <lifeless> wgrant: hah
[10:10] <lifeless> I think I speculated on that somewhere.
[10:11] <lifeless> like in the bug or something
[10:11] <wgrant> Heh, so you did.
[10:11] <wgrant> I knew it redirected, so I didn't suspect this... but I went digging, and couldn't find anything calling the handler.
[10:12] <wgrant> Sigh.
[10:12] <lifeless> I'm glad you've confirmed it
[10:12] <lifeless> it suggests an immediate obvious improvement ;)
[10:12] <wgrant> Heh, yes.
[10:12] <wgrant> Now to work out how to make it not do that.
[10:12] <lifeless> is it a systemic thing
[10:12] <lifeless> that is, do all our template render-the-GET< process-the-POST ?
[10:12] <wgrant> No.
[10:13] <wgrant> This one isn't a real form.
[10:13] <lifeless> whew
[10:13] <wgrant> So it's speical.
[10:13] <lifeless> I would have cryed.
[10:13] <wgrant> I wonder if I can stuff it into a LaunchpadFormView.
[10:15] <lifeless>  3 files changed, 16 insertions(+), 57 deletions(-)
[10:15] <wgrant> What's that?
[10:16] <lifeless> ported the fake librarian to python-fixtures
[10:16] <wgrant> Aha.
[10:17] <lifeless> I might go on a code deletion wander next week
[10:17] <lifeless> might be fun
[10:17] <lifeless> then again, I might not
[10:21] <wgrant> lifeless: What are the columns in the repeated statement report (looking at the +queue bug description)?
[10:27] <lifeless> RepsTotal timeAverage timeSavingDatabase idStatement
[10:28] <lifeless> thats
[10:28] <lifeless> reps total avg saving db statement
[10:30] <wgrant> Ah, thanks.
[10:31] <lifeless> for some reason irssi + screen turns columns from chrom into '' rather than '\t'
[13:30] <lifeless> sinzui: when you see this, I'd love to know how to show multiple batchednavigators on a single template. lib/lp/bugs/templates/bugtrackers-index.pt specifically.
[13:31] <lifeless> night all
[13:31] <sinzui> I have an example for you
[13:33] <sinzui> person.TeamMembershipView uses two subclasses of BatchedNavigator, ActiveBatchNavigator and InactiveBatchNavigator
[20:26] <JesperHansen> Seeing that launchpad is starting to modify bugreports on mozilla's bugzilla since yesterday with "See Also" links. What launchpad bug report is related to this change?
[23:27] <lifeless> JesperHansen: I'm not sure it was a bug report that drove it, rather a long term plan
[23:28] <lifeless> https://edge.launchpad.net/bugzilla-launchpad/bugzilla-3.0
[23:30] <JesperHansen> lifeless: seems that is almost year old
[23:32] <lifeless> https://edge.launchpad.net/bugzilla-launchpad/bugzilla-3.2/1.0-3.2.2 is a bit newer
[23:36] <JesperHansen> lifeless: Is "Code" page any indication of if the project is active? Says many weeks. What we're seeing is that feedback@launchpad.net has started yesterday to modify bugs
[23:38] <lifeless> what bug tracker?
[23:38] <lifeless> ah mozillas
[23:39] <lifeless> so my guess - and its only a guess - is that this was designed way back and implemented in the plugin
[23:39] <JesperHansen> And it would seem to require some rework as its modifying bugs See Also' on which the bug is RESOLVED DUPLICATE.
[23:40] <lifeless> JesperHansen: please file a bug about that
[23:40] <lifeless> launchpad.net/malone
[23:40] <JesperHansen> yea, Just trying to figure out why it has begun in the first place
[23:40] <lifeless> JesperHansen: we started syncing *into* launchpad this last week
[23:40] <lifeless> I think the plugin is doing the comments, not launchpad
[23:41] <lifeless> that is, Launchpad is saying 'we've synced comments to <location>' and the bugzilla plugin is noting and recording that.
[23:41] <lifeless> you'll have seen a lot have that happen because we've only just enabled the syncing into launchpad
[23:43] <JesperHansen> k, just beginning to see this random behaviour is hanging feedback@launchpad.net on the edge of getting a ban
[23:43] <lifeless> so
[23:43] <lifeless> first step
[23:43] <lifeless> please filea  bug
[23:44] <lifeless> if it is the plugin causing the comment to be added, banning lp won't stop it :P
[23:44] <lifeless> mkanat will know more than I about how its meant to hang together
[23:45] <JesperHansen> mkanat. I will try to remember that name
[23:46] <lifeless> max kat-alexander
[23:46] <lifeless> bugzilla upstream :)
[23:46] <lifeless> I think?
[23:47] <lifeless> sorry, Kanat-Alexander
[23:47] <lifeless> https://edge.launchpad.net/~mkanat
[23:47] <JesperHansen> That name actually rings a bell. Saw some comments or bug reports actually related to launchpad with him on bugzilla
[23:48] <JesperHansen> I am guessing that this bug https://bugs.launchpad.net/malone/+bug/596931 relates to the search for dupe'ness. But seems incomplete.
[23:49] <mkanat> Hallo.
[23:49] <mkanat> lifeless: I am around. :-)
[23:49] <lifeless> JesperHansen: no, that bug is a little different
[23:50] <lifeless> mkanat: hi; JesperHansen here is finding 'see also' links on resolved-duplicate bug reports in mozilla's bugzilla instance
[23:50] <lifeless> mkanat: since this week (which is when we turned on sync-into-lp for buzilla trackers)
[23:50] <lifeless> mkanat: I seem to recall you knowing a bit about this stuff :)
[23:50] <mkanat> lifeless: Oh, I think that gmb maintains the launchpad side of that.
[23:51] <mkanat> lifeless: I did write the Bugzilla side of it, though.
[23:51] <JesperHansen> Noticed when I got the 4th email when feedback@launchpad.net modified the 4th bugreport
[23:51] <lifeless> mkanat: yeah, I think so to; I don't know though that lp would trigger a see-also unconditionally, would it ?
[23:51] <lifeless> gmb: ^
[23:51] <mkanat> lifeless: I think that would mostly be a question for gmb.
[23:51] <lifeless> JesperHansen: gmb is in a uk tz, so won't be around now; he may well pop in in 9-10 hours
[23:52] <JesperHansen> lifeless: excellent. I am CET. Just 1 hour ahead of him
[23:53] <lifeless> JesperHansen: please file a bug though
[23:53] <lifeless> or say that you want me too
[23:53] <mkanat> lifeless: My suspicion is that launchpad is linking unconditionally.
[23:53] <JesperHansen> lifeless: I never found out how to use launchpad
[23:54] <JesperHansen> mkanat: but wasn't the plugin denied to be set in use? https://bugzilla.mozilla.org/show_bug.cgi?id=481161
[23:54] <mkanat> JesperHansen: Bugzilla 3.4 and above don't need any plugin to interact with Launchpad.
[23:54] <JesperHansen> Though you do have https://bugzilla.mozilla.org/show_bug.cgi?id=474902 which was kinda allowed over a year ago
[23:55] <mkanat> JesperHansen: Canonical is pretty much the entire reason that the See Also field exists--they funded the development of it (although it's something we wanted anyhow).
[23:55] <JesperHansen> mkanat: which was what I talked to lifeless about that I remembered seeing a bugreport or two with you :)
[23:55] <mkanat> JesperHansen: Ah, yeah. :-)
[23:56] <lifeless> JesperHansen: do you have an LP account?
[23:56] <lifeless> JesperHansen: or an Ubuntu one account?
[23:56] <JesperHansen> lifeless: Its 1am here and its pirate day, so I hope you can do it ;)
[23:57] <JesperHansen> Trying to restrict myself from doing some YARRRR
[23:57] <lifeless> sure; you'll need to subscribe to get notified of comments though
[23:58] <lifeless> https://bugs.edge.launchpad.net/malone/+bug/642418
[23:58] <JesperHansen> lifeless: I will however make a bugzilla report that you can "link" up against after making a sandwich
[23:58] <lifeless> sudo make me a sandwich?
[23:59] <JesperHansen> [sudo] password for JesperHansen:
[23:59] <lifeless> *******
[23:59] <JesperHansen> with the exception that you cant make users with capital letters