wgrant | lifeless: I'm pretty sure that 566339 is not fixed by the branch in question. | 00:16 |
---|---|---|
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:17 |
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:18 |
lifeless | you only filed it ;) | 00:19 |
wgrant | Yep. | 00:19 |
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:27 |
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:28 |
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:29 |
* 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:30 |
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:31 |
wgrant | sinzui: IMO the current translations/answers UI is a regression. | 00:33 |
wgrant | What does it even mean? | 00:33 |
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:34 |
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:35 |
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:36 |
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:38 |
wgrant | Particularly since there are a lot of Canonical projects now that only want to use one bug tracker. | 00:39 |
lifeless | s/Canonical/Ubuntu ? | 00:43 |
wgrant | lifeless: Sometimes. | 00:43 |
wgrant | But if you categorise Ubuntu One as Ubuntu, I will not be amused :) | 00:44 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
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:53 |
wgrant | If you don't want to hit the DB, you could use the pre-populated developer flag in ILaunchBag. | 00:54 |
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:55 |
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:56 |
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:57 |
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:58 |
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 | 00:59 |
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:00 |
mars | find -iname '*py' -print0 | xargs -n0 grep getFeatureFlag | sort -u | 01:01 |
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:03 |
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:04 |
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:05 |
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:06 |
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:07 |
wgrant | lifeless: Can I see OOPS-1721K2125? | 01:08 |
mars | so you could have feature:X scope:default :off | 01:08 |
mars | and feature:X scope:server.edge :on | 01:09 |
mars | Which saves you from having to write: | 01:09 |
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:10 |
mars | which is messy. You have to change the code if either of those two assumptions needs to change. | 01:11 |
lifeless | mars: code is controlled by flags | 01:13 |
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:14 |
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:20 |
mars | \o/ I get yet another opportunity to use the awesome bzr pipeline plugin | 01:25 |
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:26 |
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:27 |
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:28 |
mars | reading over what I read again | 01:29 |
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:33 |
lifeless | heh | 01:35 |
mars | ok, this stuff needs a cheat sheet | 01:40 |
lifeless | wgrant: that oops | 01:41 |
wgrant | lifeless: That oops? | 01:44 |
lifeless | ywa | 01:45 |
lifeless | looks the same as the one in https://bugs.edge.launchpad.net/soyuz/+bug/276950 | 01:45 |
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:46 |
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:47 |
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:48 |
wgrant | I might be able to reproduce it locally, then. | 01:49 |
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:50 |
lifeless | with an added helping of 'cache miss due to complex query results in reading what we had already' or some such | 01:52 |
mars | komodo only found 5 occurrances of the string getFeatureFlag() in the devel source tree... odd. | 01:53 |
lifeless | looks a little few | 01:54 |
lifeless | but not far off | 01:54 |
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:55 |
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:56 |
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:57 |
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:58 |
mars | and didn't update my source tree | 01:59 |
mars | eh? No - 'bzr switch -b' did something odd instead | 02:00 |
lifeless | mail sent to the list | 02:01 |
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:02 |
mars | ugh, sorry :( | 02:03 |
lifeless | and registry/browser/__init__.py | 02:03 |
lifeless | mars: possibly a postgresql dep change or something | 02:04 |
mars | lifeless, should feature flags return a boolean? Because the memcached one does "features.getFeatureFlag('memcache') != 'disabled'" | 02:05 |
mars | which feels a bit strange - what other values for the flag could there be? 'maybe'? | 02:06 |
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:07 |
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:08 |
mars | :/ | 02:09 |
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:11 |
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:12 |
mars | with this code, bool(getFeatureFlag('memcache')) == True, even when the memcache flag's value is 'disabled' | 02:14 |
mars | that's just not right | 02:15 |
mars | anyway, I need to run, have to put the kids to bed. ttyl | 02:15 |
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:17 |
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:23 |
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:30 |
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:36 |
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:37 |
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:38 |
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:39 |
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:40 |
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:41 |
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:42 |
lifeless | stub is looking with interest at zookeepr | 02:43 |
lifeless | who knows what else will turn up. | 02:43 |
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:44 |
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:45 |
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:46 |
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:47 |
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:48 |
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:49 |
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:51 |
mars | found it, https://bugs.edge.launchpad.net/launchpad-foundations/+bug/627701 | 02:56 |
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:18 |
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:19 |
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:20 |
sinzui | ah, we have two script and the image does not know which one to use. This may be a one line fix | 03:22 |
mars | sinzui, yep: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/11570 | 03:23 |
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:24 |
wgrant | How will that work with version selection, though? | 03:47 |
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:03 |
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:04 |
lifeless | james_w: http://pypi.python.org/pypi/fixtures updated | 04:07 |
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:22 |
lifeless | sinzui: thanks | 04:30 |
lifeless | we'll need that CP'd to production-devel | 04:30 |
lifeless | by hand | 04:30 |
lifeless | or is it the local content on disk when you submit that controls this? | 04:31 |
wgrant | Why does production need it? | 04:32 |
wgrant | Isn't production still 8.3, so EC2 should probably use 8.3 too? | 04:33 |
lifeless | wgrant: we need to keep running ec2 land for prod-devel branches | 04:34 |
lifeless | do you have reason to think that that isn't affected in the same way? | 04:35 |
wgrant | True. | 04:35 |
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:38 |
wgrant | Although there was a bit of specialness WRT that this cycle... | 04:44 |
lifeless | this is not the patch you are looking for | 04:46 |
wgrant | Hm. | 05:17 |
wgrant | The Django Debug Toolbar is handy. | 05:17 |
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:19 |
lifeless | wgrant: K, I'll probably be around if you want to bounce ideas | 05:20 |
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:21 |
wgrant | Ahem. | 05:22 |
lifeless | :) | 05:23 |
wgrant | lifeless: Do you know if there's a known issue with the revision karma allocator? | 05:37 |
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:40 |
lifeless | not aware of any incident report about it | 05:42 |
* StevenK kicks Maven until pieces fall off | 05:50 | |
lifeless | anyone know the list that zope testing patches and plans are designed on? | 08:16 |
lifeless | wgrant: https://bugs.edge.launchpad.net/soyuz/+bug/629921 -please- | 09:21 |
lifeless | I'm begging you. | 09:21 |
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:23 |
wgrant | But anyway, let's see how difficult that is... | 09:24 |
wgrant | Ahh, I see. | 09:24 |
wgrant | lifeless: Am I allowed to violate the no-implicit-truth guideline? That would reduce the fix to deletion of a few characters... | 09:25 |
lifeless | wgrant: no implicit truth? | 09:26 |
wgrant | lifeless: It's suggested not to say 'if whatever' -- instead we are told to say 'if whatever is not None' | 09:27 |
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:28 |
lifeless | given I just wrote email to the list suggesting *just that* for flags earlier today :) | 09:29 |
* wgrant fixes the Maverick psycopg2 compatibility breakage. | 09:48 | |
lifeless | its compatible; honest. | 09:49 |
wgrant | It is, but our celebrity code sucks. | 09:49 |
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:06 |
wgrant | WTF | 10:08 |
wgrant | WTF | 10:08 |
wgrant | WTF | 10:08 |
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:09 |
lifeless | wgrant: hah | 10:10 |
lifeless | I think I speculated on that somewhere. | 10:10 |
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:11 |
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:12 |
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:13 |
lifeless | 3 files changed, 16 insertions(+), 57 deletions(-) | 10:15 |
wgrant | What's that? | 10:15 |
lifeless | ported the fake librarian to python-fixtures | 10:16 |
wgrant | Aha. | 10:16 |
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:17 |
wgrant | lifeless: What are the columns in the repeated statement report (looking at the +queue bug description)? | 10:21 |
lifeless | RepsTotal timeAverage timeSavingDatabase idStatement | 10:27 |
lifeless | thats | 10:28 |
lifeless | reps total avg saving db statement | 10:28 |
wgrant | Ah, thanks. | 10:30 |
lifeless | for some reason irssi + screen turns columns from chrom into '' rather than '\t' | 10:31 |
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:30 |
lifeless | night all | 13:31 |
sinzui | I have an example for you | 13:31 |
sinzui | person.TeamMembershipView uses two subclasses of BatchedNavigator, ActiveBatchNavigator and InactiveBatchNavigator | 13:33 |
=== jcsackett_ is now known as jcsackett | ||
=== Ursinha-afk is now known as Jorjao | ||
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? | 20:26 |
=== Jorjao is now known as Ursinha | ||
=== almaisan-away is now known as al-maisan | ||
=== al-maisan is now known as almaisan-away | ||
lifeless | JesperHansen: I'm not sure it was a bug report that drove it, rather a long term plan | 23:27 |
=== Ursinha is now known as Ursinha-afk | ||
lifeless | https://edge.launchpad.net/bugzilla-launchpad/bugzilla-3.0 | 23:28 |
JesperHansen | lifeless: seems that is almost year old | 23:30 |
lifeless | https://edge.launchpad.net/bugzilla-launchpad/bugzilla-3.2/1.0-3.2.2 is a bit newer | 23:32 |
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:36 |
lifeless | what bug tracker? | 23:38 |
lifeless | ah mozillas | 23:38 |
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:39 |
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:40 |
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:41 |
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:43 |
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:44 |
JesperHansen | mkanat. I will try to remember that name | 23:45 |
lifeless | max kat-alexander | 23:46 |
lifeless | bugzilla upstream :) | 23:46 |
lifeless | I think? | 23:46 |
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:47 |
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:48 |
mkanat | Hallo. | 23:49 |
mkanat | lifeless: I am around. :-) | 23:49 |
lifeless | JesperHansen: no, that bug is a little different | 23:49 |
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:50 |
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:51 |
JesperHansen | lifeless: excellent. I am CET. Just 1 hour ahead of him | 23:52 |
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:53 |
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:54 |
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:55 |
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:56 |
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:57 |
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:58 |
JesperHansen | [sudo] password for JesperHansen: | 23:59 |
lifeless | ******* | 23:59 |
JesperHansen | with the exception that you cant make users with capital letters | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!