[09:20] it hasn't [09:20] Heaven help me, one of the ladyboys next door is singing. Badly. [09:22] Makis: unless they just changed, I don't think you read the instructions right. :-) [09:22] ok, i was able to download the file successfully from your link [09:23] (I'm trying to reproduce from the instructions now. I'll probably end up with egg on my face. :-) [09:23] this command however didn't work: bzr --no-plugins cat http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/utilities/rocketfuel-setup > rocketfuel-setup [09:24] i don't know if something was broken because i tried that yesterday. i did clean /etc/hosts, but maybe something else was changed as well [09:25] i had to stop the script because download speed for the trunk was 0kb/s, i had it running from yesterday afternoon to this morning and it had downloaded less than a megabyte, but i think i now know why [09:25] Makis: quite possibly... aiui the lp: protocol was redirected to go over http for the duration. [09:26] Salut les Launchpaddeurs :) [09:26] mrevell: et toi, le plus grand launchpaddeur de tous [09:26] jtv: pas de tous, mon ami de l'est [09:27] mrevell: je ne suis pas de l'est, c'est seulement que je vive ici [09:27] Makis: funny... I can "bzr branch" off lp:~launchpad-pqm/launchpad-devel but I can't "bzr cat" a file out of it. [09:28] Makis: and the _really_ funny part is that "bzr cat" seems to insist that the branch must be in my home directory. [09:28] jtv: Mais, je me demande combien des ans il fault que tu vives la devant tu peux dire que tu veins de l'est. Okay, enough :) [09:29] mrevell: quite. [09:29] mrevell: it's only a small step from there to "how many roads must a man walk down" [09:29] (the answer is zero, by the way: the hypothetical man is already a man by the assumptions made in the question) [09:30] :) [09:30] * mrevell goes to create #launchpad-philosophy [09:30] mrevell: it'll be only you, so a nice exercise in solipsism. [09:30] :) [09:30] And if you leave, will the channel be nihilist? [09:31] Then again, existentialism says you have to do it in order to validate your existence [09:31] Personally I prefer Meatloaf. [09:31] Makis: don't let this babbling fool you, I'm still experimenting [09:34] kfogel, when you get here (*much* later I hope), Makis' problem will interest you: errno -2 while trying to obtain rocketfuel-setup with "bzr cat" as documented on https://dev.launchpad.net/Getting [09:34] jtv: Maybe a glitch - we have only seen the spikes today. I don't see any previous spikes like this looking at the monthly or yearly graphs. [09:35] jtv: Are aborted poimport jobs retried automatically? [09:35] stub: nope [09:35] they fail, and if they fail this dramatically, there'll be no error output. [09:35] jtv: Can we manually retry the jobs that failed today? [09:35] What surprises me is that I haven't seen it show up on error-reports either. [09:35] Hmm [09:36] stub: we don't know exactly which ones will have failed today, but we can reset the status on recent FAILED uploads with error_output IS NULL [09:37] Will that annoy users? [09:37] stub: I don't think so. As long as we do this only for recent uploads, these are cases where the uploader should have been notified but wasn't. [09:37] If 'no' or 'not much', it sounds worth a go to see if we can reproduce the problem. [09:38] So set status back to 1 where it was 4, and where dateimported (a blatant misnomer) is not much older than the 24th, and error_output is null. [09:40] spm, still here? You shouldn't be, but if you are, you wouldn't know of anything changed with our setup for users getting RF in the past day or so would you? [09:40] who decided that TAGS over site-packges was a good idea? [09:41] UPDATE TranslationImportQueueEntry SET status=1 [09:41] thumper: I don't know, but let's just blame Bill gates like we always do. [09:41] WHERE status = 4 and error_output is null and dateimported > date '2009-08-03' [09:41] Sorry - 24th [09:41] stub: and month 07, and day 23 :-) [09:41] UPDATE TranslationImportQueueEntry SET status=1 [09:41] WHERE status = 4 and error_output is null and dateimported > date '2009-07-23' [09:41] stub: then, plug your ears, crouch behind a solid object, and watch the importer go to work. [09:42] yup, that looks right [09:42] 778 [09:42] * thumper gets the desire to smack someone around [09:42] I'll avoid looking at bzr blame [09:43] thumper: no, do look at bzr blame. At least that way I'm reasonably sure I'll be safe personally. [09:43] stub: that's quite a lot. [09:43] stub: I should have seen lots of complaints on error-reports about that... [09:50] stub: useful piece of trivia here: dateimported is the date of the original upload. It does not get updated during import, or subsequent upload of a newer version of the same file, or anywhere else. [09:51] sounds like that needs expanding [09:52] stub: dateimported should actually be called date_uploaded. [09:52] stub: it is the creation date of the import queue entry. [09:52] hey wgrant, thanks for taking on bug 385129 [09:52] Bug #385129: add PPA dependencies information to the api [09:52] I'd have date_created and date_uploaded if you can upload a newer version, or something like that [09:53] stub: we gave it a better name in the web service API, but haven't bothered to rename the attribute itself. [09:53] Hmm... we have two poimport connections [09:53] There can be only one. [09:54] Unless one is for the slave. [09:55] Nah - one for the lpmain replication set, one for the authdb replication set [09:55] Actually, scrub that [09:55] does it make sense for a script like this to talk to the authdb? [09:55] jtv: poimport emails don't go to error-reports anymore, don't they? [09:56] danilos: oh, that must be it. Don't know why, but I thought that'd been reverted. [09:56] Hi btw :) [09:56] jtv: yeah, hi :) [09:56] jtv: we've got stuff like http://launchpadlibrarian.net/29834164/uK8pt7QInv178EM0SyyuKEuaZai.txt [09:56] danilos: henning's still sick :/ [09:56] jtv: https://pastebin.canonical.com/20726/ -- same database, same db user, both tables only available in the lpmain replication set. [09:57] jtv: yeah, noticed [09:57] hello everyone [09:57] hi jml [09:58] jml: hello [09:59] stub: iirc the script is supposed to lock... [09:59] jtv: Looks like approve imports is connecting as the poimport database user? [09:59] wuu, all the hip .eu people are around :) [09:59] jtv: poimport logs on devpad have a lot of tracebacks like this [09:59] oh, yes, that could be it. [09:59] jml: all the hip .eu people *and* me too :) [09:59] danilos: where did those logs live again? [10:00] jtv: let me check, I've got a symlink in my devpad $HOME [10:00] jtv: devpad:/srv/launchpad.net-logs/scripts/loganberry [10:01] danilos: thanks [10:01] https://bugs.edge.launchpad.net/rosetta/+bug/118633 [10:01] Bug #118633: pofile import approver should connect as a different database user [10:02] jtv: thanks for your help, it seems our corporate network is blocking ssh so that's why the download of the trunk didn't work [10:02] jtv: many, many failures like this since the rollout, I can take a look myself [10:02] Makistos: but the "bzr cat" went over http... [10:02] danilos: thanks, then I'll go back to the message-sharing. [10:03] yeah, but at least i got the thing working by downloading the setup script from your link and using a different network for the rest [10:05] Makistos: glad to hear it. [10:06] stub: so we're getting a lot of nasty import failures that aren't visible on error-reports anymore. :-( [10:08] I'm creating a celebrity team [10:08] and I need to put it into the sample data [10:08] what should be the PersonCreationRationale for the team owner? [10:09] jml: what celebrity team are you creating? [10:10] thumper, techboard [10:10] thumper, it's actually already referred to in the code, but not as a celebrity. [10:10] ew [10:10] exactly [10:10] so I'm fixing that before I proceed to write some tests that actually need to use it [10:11] I'm going with PersonCreationRationale.UNKNOWN for the time being [10:15] jml: did you see that mwhudson fixed the setBranch API bug? [10:16] thumper, yes, I saw that. [10:16] very embarrassing [10:16] bigjools: cprov suggested it. I did the read-only export hours ago, but do you think exposing {add,remove}ArchiveDependency is useful? [10:16] * thumper shrugs [10:16] jml: sometimes it just takes someone else to look at it [10:16] jml: people can be too close to the code sometimes [10:17] I'm about to propose a branch for merging that _may_ be causing our segfaults [10:17] wgrant: it depends on who would use it, nobody I know needs that right now, so if you don't need it, leave it for later. [10:17] anyone interested in reviewing it? [10:17] * thumper should go to #launchpad-reviews [10:19] bigjools: It'd also need some shuffling of the security checks from browser code to model code, so it's not just a trivial export. I'll leave it. [10:19] wgrant: don't put security checks in model code [10:19] bad bad idea [10:20] security checks go in the ... gasp.... security code :) [10:21] bigjools: Well, yes, but I'm not sure how that would work in this case. The restriction in question is that the user must be able to view the PPA to add it as a dependency. [10:22] Although that's already done in syncSource, so I might look there just to see how it's done. [10:22] Oh, that just works because getPublishedSources is secured. [10:22] wgrant: it's done in the security adapter [10:23] bigjools: But it depends on an argument, not the context or method. [10:23] addArchiveDependency doesn't need to do anything to the dependency argument, so no checks are ever done. [10:24] So you get nasty nasty bugs like that one in January. [10:24] if the security adapter is set up properly, it will be okay [10:24] it's not always possible to make the decision there though [10:25] I don't think it's possible. [10:25] upload ACLs being one example [10:25] Right. [10:25] How would a security adapter catch this case? [10:25] bigjools, :) [10:25] jml: :D [10:26] wgrant: you would need lp.Edit on the archive [10:26] bigjools: You need lp.Edit on the dependent archive to call the function, but not the dependency archive. [10:26] bigjools: Unless you explicitly check for the permission in addArchiveDependency, which is probably bad. [10:27] right, you need lp.view on it [10:27] which will get checked in the sec adapter as soon as you try to reference it [10:28] write a doc test, you will see (I hope) [10:31] night all [10:32] Enjoy your evening thumper [10:32] thumper, g'night [10:41] bigjools: Why would the security adapter fail an attempt to reference the archive? [10:41] Everybody can get the distro of a P3A. [10:41] And other stuff. [10:41] hmph [10:41] And can't I pass a securityproxy'd object around as much as I want? [10:41] It only cares if I try to access attributes. [10:42] pesky kids [10:43] wgrant, you can pass around a securityproxy'd object as much as you want. [10:43] that's what he said [10:43] we could do with views for API calls [10:43] So if I don't try to do anything to it, I will never die. [10:43] bigjools: Right. [10:44] some of the model code takes a user parameter.... ewww [10:44] bigjools, it's not the worst thing in the world [10:44] bigjools, granted, it's not ideal. [10:45] well it means that the content class becomes tied to a request [10:45] there's a way of saying 'this parameter is the logged-in user' in the API permissions. [10:45] bigjools, not necessarily [10:45] yes, I hate that [10:45] our content classes are already huge :( [10:45] bigjools, ISourcePackage.setBranch for example, the user parameter is the registrant. That's very much a model-level detail. [10:45] jtv: Perhaps create a new rationale? [10:46] stub: did you mean jml? [10:46] jml: that case is fine [10:46] I guess the existing ones would be lies then [10:46] Yup - jml [10:46] stub, UNKNOWN is only a white lie :) [10:50] bigjools: Anyway, I will go with read-only for now. [10:51] wgrant: good plan [10:51] baby steps, and all that [10:52] jml: btw, the extra info on the pqm landing emails is top drawer [10:53] stub, 'make newsampledata' generates a file without a copyright statement, which leads to spurious diffs -- how would I fix that? [10:54] bigjools, thanks, but I'm pretty sure that wasn't me :) [10:54] jml: you're the only representative from the code team who's awake right now :) [10:55] :) [10:58] stub, I'm thinking that I should change the 'build_new_sampledata' definition in database/schema/Makefile to echo the copyright statement to the file. [10:58] * jml just does that. [10:59] sounds sane [11:06] hmm. a lot of targets in this makefile don't actually create files named after the target, and aren't included in phony. [11:26] danilos, that diff vous wanted: https://code.edge.launchpad.net/~jtv/launchpad/bug-408206/+merge/9579 [11:26] jtv: looking [11:30] how do I determine which config is being used? [11:33] stub, can I get 'make harness' working from launchpad_ftest_playground? I want to use it to add some test sampledata. [11:33] bigjools: One questionable thing I did to get the export of IArchiveDependency working was replace IAD.archive's Choice over the PPAVocabulary with a plain Reference, or lazr.restful ignores it in the WADL export. Should I instead create a PPAChoice? [11:34] let me check [11:34] jml: make harness LP_DBNAME=launchpad_ftest_playground might work [11:34] jtv: it is simple enough, but without checking that it really helps, I'd really like to avoid asking for a cherrypick [11:35] oh huh... 'make harness LPCONFIG=test-playground' is actually mentioned in the README. [11:36] My method doesn't work [11:36] stub, I'm just verifying my method. [11:36] * jml might tweak the README to make this more obvious. [11:37] danilos: we can be pretty sure it helps with the "commit more often" problem. :-) [11:37] (Which is actually what triggered all the other problems) [11:39] jtv: yeah, but "making stub happier" is usually not a good enough argument for a CP, even though we can argue if it should be :) [11:39] wgrant: I don't know what the right thing to do is here, and I don't know why the existing choice would not get exported [11:40] bigjools: I think it's because it has no explicit interface. [11:40] danilos: "make mvo happier" maybe? :) [11:40] jtv: heh, that is, but only if we can show that it will make him happier :) [11:40] wgrant: could be, stuff like PublicPersonChoice inherits from ReferenceChoice [11:40] danilos: alternatively, we can tell mvo to STAY AWAY FROM OUR SHINY DATABASE for now. :-) [11:40] bigjools: PublicPersonChoice is able to be exported, and it basicall just has the interface set. [11:40] bigjools: Ah, true, that too. [11:41] (I tried to contact him yesterday, but no luck) [11:41] wgrant: ok, give PPAChoice a try, but call it ArchiveChoice [11:41] jtv: no, alternatively, we can try this out on staging, and then see if it will fix stuff for mvo, and then ask or not for a CP [11:41] wgrant: actually no, PPAChoice [11:41] bigjools: Doesn't it actually want to be restricted to PPAs, though? [11:41] yeah [11:41] danilos: once staging is working again, of course. Absolutely. I'm talking only about what we do until then, if it takes longer. [11:41] Right. [11:43] jtv: well, do you know what's up with staging restores? they are not working either [11:44] danilos: no, they haven't been working lately but I think there was no error—which would probably mean there's a deliberate lock stopping them. I mentioned it in my email to the LOSAs, so presumably they know about it. [11:48] make schema takes way too long :( === noodles775 is now known as noodles775-afk [11:52] danilos: The long running transactions are victimizing other parts of the system. We either need to cherry pick the fix, or I need to be more aggressive about killing long transactions (and killing your jobs). [11:53] RAOF, hello [11:54] stub: certainly, but that doesn't mean that we should cherrypick something without testing it on staging first (which is what jtv and I were discussing); fwiw, this might still be using long transactions, and we have symptoms which can tell us if they are [11:54] bigjools: Some grepping around showed I just needed to replace the Choice with a lazr.restful.fields.ReferenceChoice and specify a schema. Now it all works. [11:54] ah! [11:54] danilos: Sure. [11:54] wgrant: I am shocked that you didn't have to deal with circular imports [11:54] circular import DEATH HELL [11:54] bigjools: I did. [11:54] bigjools: But they were easily patched. [11:55] danilos, stub: for now at least, the problems aren't happening because that one large export has been disabled. [11:55] ah good, sometimes they are not. I hope you liked my patch_ funcs :) [11:55] bigjools: They're very useful. [11:55] jtv: right, but we need to re-enable it on staging and test it [11:55] jml: Hello there. [11:55] jtv: I'll email mvo about it [11:56] danilos: absolutely. But again, talking about the very short term until we can do that. [11:56] inline bug commenting ROCKS [11:57] jtv: we've got a workaround for the time being: email mvo and disable ddtp bzr exports; a week of waiting won't kill him, I believe [11:57] danilos: I had already disabled them, so we're in the clear for now. The last run succeeded. [11:58] jtv: right, but mvo is unaware :) I'll email him (CCing you) and mention the bug we are working on [11:58] danilos: thanks. [12:19] bigjools, hi [12:19] helleau [12:20] bigjools, who owns the 'build source packages from branches' task? [12:20] I don't think anyone does yet [12:20] Tim and I talked about it [12:20] bigjools, cprov, james_w & I specced out a solution at UDS, and I saw you mention that you & Tim talked about it [12:21] & mwh @ UDS [12:21] yeah, it's not as trivial as first thought [12:21] we need to have a job farm like PPA builders that run VMs that will do the bzr builddeb stage [12:21] yes. [12:21] that's what we've got on our spec [12:22] good, so far :) [12:22] (which currently lives on a big sheet of butcher's paper in my backpack) [12:24] * jml is trying to think of the next step here [12:24] it's a very important feature, someone ought to own it, and I don't think I can reasonably volunteer. [12:24] although I'd rather like to. [12:24] jml: I can suggest transferring your notes to a blueprint [12:25] bigjools, yeah, that will definitely happen [12:25] :) [12:27] jml: the first step is to break the work up into chunks, I think "someone" will be >1 person [12:27] bigjools, the project still needs a single person to own it though [12:28] jml: not necessarily, but yes it does need a single person up front to do the initial breakdown [12:28] I think most of the work is on the Soyuz side [12:28] and IS [12:28] so it might make sense for me to own it [12:29] bigjools, fair enough. I think the main idea is that someone needs to be able to answer the question "how are we going with the build a branch from source package work?" [12:29] bigjools, I'll put the spec into a blueprint & send a message to the dev list & your good self. [12:30] okiedokie, thanks [12:38] bigjools, btw, liw just sent a spec / rfc to the launchpad-dev list that you might be interested in. [12:39] jml: ok, it's not arrived yet but I'll take a butchers in a bit [12:40] * jml gains rhyming slang xp === noodles775-afk is now known as noodles775 === salgado-afk is now known as salgado [13:16] herb: nag time again. See my email to the losa list... could you run it with LP_DEBUG_SQL_EXTRA enabled so it creates a full log of what's going on? [13:23] Why does checkwatches chew up so much CPU on the DB server. I would have thought the database side was trivial with all the time spent talking to the remote sites. [13:25] BjornT: Do you think this is expected, or should I open a bug and try to get some statement logs to see what it is doing. Might be missing an important index or something. [13:31] stub: i was going to look into that. checkwatches take much longer to run before, but i don't know why yet. the database side should be trivial [13:32] It might be obvious from the statement logs. === mrevell is now known as mrevell-lunch === Edwin is now known as Guest81640 === Guest81640 is now known as EdwinGrubbs [14:54] noodles775: ping [15:39] jtv: beuno. I have been thinking about application pages (translations.launchpad.net) and collection pages (/people). I suspect they are locationless, but unlike the other location pages we have, these are prominent. [15:40] jtv: beuno: this is like the global search issue. There is no pillar or person to create branding and tabs for. What are we showing at the top of the page? [15:42] sinzui: I don't think I'd like these to be locationless. That top tabs bar on the front page is such a nice way to get a quick top-level overview. [15:42] jtv: I think you are right [15:44] In fact I get a reasonable approximation of the front pages we know and love by using main_side and moving the buttons list into the side slot. [15:45] jtv: beuno: I wonder if we need an alternate layout (and heading) for application pages (which are roots) and /people /bugtrackers with was collections in rooted apps [15:45] sinzui, on a call for another hour [15:45] but I'll think about it [15:45] beuno: understood [15:46] sinzui, I suspect we could just find a good context instead [15:46] users have a different perception of context than we do [15:47] sinzui: another question I had... we still have a few isolated actions menu items here and there. If we are to move those inline, do we replicate the permissions requirements in the TAL conditions? [15:50] does launchpad go through any load testing? [15:50] jtv: put the links in a menu so that the permissions and text are consistent [15:50] slytherin: mostly by actual use. Why? [15:51] sinzui: what kind of menu? === noodles775_ is now known as noodles775 [15:51] jtv: just curious. I recently packaged jakarta jmeter for Ubuntu. It is a good application to do load/stress testing of web applications. [15:51] jtv: If the links act on the context in a global way (change details) then it may go side portlets [15:51] herb, got time for my script run today? Nag, nag. :-) [15:51] any vim users about? [15:52] I have an emacs thing that makes it really easy to run 'bzr ls -VR --kind=file --null | xargs -0 grep -In ' in the editor [15:52] mars: see slytherin' [15:52] jtv: as for menus, I have placed links in application menus (overview for my app) and in navigation menus (for views that share menus) [15:52] lots of our emacs users love it, since it makes it really easy to find obscure code in launchpad [15:52] s note [15:52] how can this be bundled to provide similar joy for vim users [15:52] jtv: yes. in a few minutes. [15:53] herb: cool thx [15:53] jml: what does that do? [15:53] bigjools, it greps all of the version controlled files in a branch that aren't binary files [15:54] jml: I have an LP vim hacking page on the old lp wiki [15:54] jtv: While we thought we were getting rid of navigation menus, this was wrong. The new design encourages them in fact. I do not think we will have navigation menus on model objects though, or sub menus. We just need to define sets of links that are common to a set of pages [15:54] jml: I will migrate it and add your special bzr-fu command [15:55] Ursinha, ping, ^ regarding slytherin's question, do you know how far matsubara got with the stress testing tools? [15:55] bigjools, cool, thanks. [15:55] bigjools, it's generically useful for bzr. you might want to look at the .el file linked from https://dev.launchpad.net/EmacsTips for how it works in practice [15:56] sinzui: will the existing app menus still show up in the new macros then? [15:56] sinzui: sorry, nav menus. [15:57] No, beuno hates that design. [15:58] * jtv wishes UI design would stop affecting the code :-) [15:58] jtv: I dismantled the product edit nav menu, then realised that I put the same set of links on 5 pages. So I restored the navigation menu and used it to define the canonical set of links for edit pages. [15:58] jtv, we all do ;) [15:58] beuno: stay out of this. You're the one causing this pain. :-P [15:59] sinzui: so what did you do to make the nav menu show up in the actual page again? [16:00] jml: I'd rather not look at *any* .el file ;) [16:00] jtv: I don't think navigation menus on context objects will be needed. The ones on the view still have value. Move the links into the main content area. If you have a set of "related pages" that you want that should be shown use the view/@@/+related-pages call to generate a portlet of related pages [16:01] bigjools, :) [16:01] gary_poster, I just filed https://bugs.edge.launchpad.net/launchpad-foundations/+bug/408897 -- maybe it's not appropriate [16:01] Bug #408897: Use latest zope.testing [16:01] for reference: https://dev.launchpad.net/UltimateVimPythonSetup [16:01] mars: actually that was me, I was working with FunkLoad [16:01] sinzui: ah, I just read about that transformation. [16:01] me and stub [16:01] jtv: look at lib/lp/registry/templates/product-edit.py for an example of how a nav menu went from being implicitly rendered by the layout to explicitly rendered by the template. [16:01] (but I just came across a corker of a testrunner bug while helping cjwatson with his python2.5-based Launchpad development) [16:02] sinzui: cool, examples are good. Thanks. === Ursinha is now known as Ursinha-lunch [16:02] jml: have you seen ack-grep BTW? [16:02] bigjools, the name rings a bell. [16:02] it's written in perl but I won't hold that against it (too much) [16:02] sinzui: I don't mind (well, not very much) the menu as a whole needing some work, but I didn't want to have to find a new home for every link in it and make sure it shows up at the right times. :) [16:02] Ursinha, slytherin was just wondering if we wanted to try out jmeter, as he has packaged it for the base distro [16:03] jtv: I did a small refactoring the the ProductEditNavigationMenu. I moved the links it uses and the overview menu uses to a mixin to ensure they links had the same implementation...they were different in the menus [16:04] jtv: if the information does not naturally fit in the content, but users will realise after reading the page that they want to know more about the subject, use a navigation menu and the +related-pages. call [16:04] jml: ok, cool. sorry for the pain. the zope buildout branch is next in line for me to return to it. :-) :-/ [16:05] sinzui: a mixin sounds like a nice solution. [16:05] * bigjools curses at the miserably crap GTK file-open dialog corrupting the perfection of KDE4 [16:05] gary_poster, no worries at all. just wanted to know, since a lot of this python upgrade stuff is still fairly opaque. [16:06] jml: I have no idea what that dot hell file is doing, I will need help to convert to a vim macro :( [16:06] jml: you mean, wanted to know if we planned to move to a newer version of zope.testing? or where we were in the process? [16:06] sinzui: none of this is particularly good for our single-option admin-only "edit this object" links, but maybe there mentioning the privilege in TAL isn't so bad. [16:07] hijacker_, sinzui. I wanted to work on bug #315858. It's marked Fix Released, but I can't understand why. Also looking at rev 7974 I don't find anything useful. Could you help me? [16:07] Bug #315858: It's not obvious how to subscribe to a mailing list

[16:08] jml: http://paste.ubuntu.com/247277/ is the "wcgrep" thing I use; I believe I nicked it from the Subversion tree years ago and hacked on it as needed [16:08] jml: does emacs have python bindings? [16:08] andrea-bs: I think we should avoid working on this issue until launchpad engineers stop giving teams and subscriptions dual roles of communication and permissions. The situation is completely buggerd [16:09] jml: How is cjwatson doing his python2.5-based Launchpad development, ooi? Using what I've noted on http://dev.launchpad.net/LaunchpadOnKarmic or an independent effort? [16:09] andrea-bs: It is never clear how to get a mailing-list even if you can read the code and see in the database. The fix we did was better. We can try to improve it in the team redesign [16:09] maxb: I'm using your stuff [16:09] yay :-) [16:10] well, more or less, it's been a little while since I synced [16:10] *please* get that merged if at all possible :-) [16:10] I still haven't managed to convince the testsuite to run all the way through [16:10] I'm not even trying [16:10] maxb: you don't have to get the test suite to run all the way through in Py 2.5 to commit [16:11] maxb: you have to get it to run in 2.4 [16:11] so maybe that would make it easier to make incremental checkins? [16:11] (s/commit/merge) [16:11] andrea-bs: The problem is that if a team creates a mailing list, the team is clearly intended for communication, so every member should get the list mail. Instead of addressing the use case and rethinking the purpose of teams, we introduced a maze of rules for the team owner and team member to negotiate. [16:12] I really ought to get myself a working 2.4 environment. I don't have one at the moment. [16:12] maxb: sounds like a plan ;-) [16:13] it's a right pain to do in karmic. I tried briefly but life is too short. [16:13] jtv: devpad:/home/herb/jtv.out [16:13] (chroots are of course possible) [16:13] herb: great, thanks. [16:14] cjwatson: granted :-/ [16:14] also, OMG distroseries.createUploadedSourcePackageRelease is a painful interface [16:14] heh [16:14] herb: this time I caught the bugger with an explicit sync, just what I needed to pinpoint it. [16:14] sinzui, I see that the situation is a bit complex :) Thank you for the clarification. [16:17] andrea-bs: I really want it to be simple. I have a bug that is blocked by this situation. As a team owner, I want to send an important message to each member. I cannot because user can be unsubscribed from the list, they may not even know they are unsubscribed. [16:18] sinzui, I know: I have reported a bug describing the same situation [16:20] andrea-bs: there was a proposal to add a bool to the team model to indicate that the team is intended for communication. I am not sure it is needed. We just need to guard the situation where the team can be placed in the dual roles of communications and ACL. We just need to ask the owner to confirm his choice, and give him an option to create another team to fill the needed role. [16:28] beuno, you don't have a mockup of the project/distro page, like the one you have for the person page? [16:30] sinzui, As a team and project owner, I think that having separate teams for communications and ACL is a bad idea, because one can end up with too many teams. Instead I think that mailing lists should be less team-depended: for example anyone should be able to subscribe to a mailing list, also without being a member of the team (because often a mailing list is not just for members, but also for people who would like to [16:30] become a member). [16:31] andrea-bs: that has beend discussed too. When we list all the features user expect it to have, see it behaves like a team. IT has to support the same rules of aggrigation of membership [16:32] andrea-bs: There is another rule that any person of good launchapd standing should be able to post a message to any public list [16:32] andrea-bs: and any person should be able to receive list mail even if he is not a member of a team [16:42] sinzui, I agree that, in a sense, mailing list should behave like teams. But I think that having two real teams (one for ACL and one for communications) is really a bad idea because makes the work really harder: when someone wants to register a team, (s)he has to register two teams; when a member wants to join/leave a team, (s)he has to join/leave two teams; when an admin wants to change the icon of the team he has to [16:42] do this twice and so on... [16:42] sinzui, Also, and this is for me the most important point, the team/project owner has to tell the community to join two teams and why they should do this. Explaining such things to someone who has never used Launchpad before can be really difficult. [16:43] hmm. so enforcing the communications team split would in effect be encoding policy into Launchpad [16:43]

rule to the new CSS. This does not look very good. What can he change in the project page to make all content look good with this

? === abentley1 is now known as abentley [23:55] phew [23:55] finally [23:56] inbox has no unread emails