[09:20] <Makis> it hasn't
[09:20] <jtv> Heaven help me, one of the ladyboys next door is singing.  Badly.
[09:22] <jtv> Makis: unless they just changed, I don't think you read the instructions right.  :-)
[09:22] <Makis> ok, i was able to download the file successfully from your link
[09:23] <jtv> (I'm trying to reproduce from the instructions now.  I'll probably end up with egg on my face.  :-)
[09:23] <Makis> 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] <Makis> 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] <Makis> 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] <jtv> Makis: quite possibly...  aiui the lp: protocol was redirected to go over http for the duration.
[09:26] <mrevell> Salut les Launchpaddeurs :)
[09:26] <jtv> mrevell: et toi, le plus grand launchpaddeur de tous
[09:26] <mrevell> jtv: pas de tous, mon ami de l'est
[09:27] <jtv> mrevell: je ne suis pas de l'est, c'est seulement que je vive ici
[09:27] <jtv> 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] <jtv> Makis: and the _really_ funny part is that "bzr cat" seems to insist that the branch must be in my home directory.
[09:28] <mrevell> 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] <jtv> mrevell: quite.
[09:29] <jtv> mrevell: it's only a small step from there to "how many roads must a man walk down"
[09:29] <jtv> (the answer is zero, by the way: the hypothetical man is already a man by the assumptions made in the question)
[09:30] <mrevell> :)
[09:30]  * mrevell goes to create #launchpad-philosophy
[09:30] <jtv> mrevell: it'll be only you, so a nice exercise in solipsism.
[09:30] <mrevell> :)
[09:30] <jtv> And if you leave, will the channel be nihilist?
[09:31] <jtv> Then again, existentialism says you have to do it in order to validate your existence
[09:31] <jtv> Personally I prefer Meatloaf.
[09:31] <jtv> Makis: don't let this babbling fool you, I'm still experimenting
[09:34] <jtv> 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] <stub> 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] <stub> jtv: Are aborted poimport jobs retried automatically?
[09:35] <jtv> stub: nope
[09:35] <jtv> they fail, and if they fail this dramatically, there'll be no error output.
[09:35] <stub> jtv: Can we manually retry the jobs that failed today?
[09:35] <jtv> What surprises me is that I haven't seen it show up on error-reports either.
[09:35] <stub> Hmm
[09:36] <jtv> 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] <stub> Will that annoy users?
[09:37] <jtv> 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] <stub> If 'no' or 'not much', it sounds worth a go to see if we can reproduce the problem.
[09:38] <jtv> 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] <jtv> 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] <thumper> who decided that TAGS over site-packges was a good idea?
[09:41] <stub> UPDATE TranslationImportQueueEntry SET status=1
[09:41] <jtv> thumper: I don't know, but let's just blame Bill gates like we always do.
[09:41] <stub> WHERE status = 4 and error_output is null and dateimported > date '2009-08-03'
[09:41] <stub> Sorry - 24th
[09:41] <jtv> stub: and month 07, and day 23 :-)
[09:41] <stub> UPDATE TranslationImportQueueEntry SET status=1
[09:41] <stub> WHERE status = 4 and error_output is null and dateimported > date '2009-07-23'
[09:41] <jtv> stub: then, plug your ears, crouch behind a solid object, and watch the importer go to work.
[09:42] <jtv> yup, that looks right
[09:42] <stub> 778
[09:42]  * thumper gets the desire to smack someone around
[09:42] <thumper> I'll avoid looking at bzr blame
[09:43] <jtv> thumper: no, do look at bzr blame.  At least that way I'm reasonably sure I'll be safe personally.
[09:43] <jtv> stub: that's quite a lot.
[09:43] <jtv> stub: I should have seen lots of complaints on error-reports about that...
[09:50] <jtv> 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] <stub> sounds like that needs expanding
[09:52] <jtv> stub: dateimported should actually be called date_uploaded.
[09:52] <jtv> stub: it is the creation date of the import queue entry.
[09:52] <bigjools> hey wgrant, thanks for taking on bug 385129
[09:52] <mup> Bug #385129: add PPA dependencies information to the api <api> <ppa> <Soyuz:In Progress by wgrant> <https://launchpad.net/bugs/385129>
[09:52] <stub> I'd have date_created and date_uploaded if you can upload a newer version, or something like that
[09:53] <jtv> stub: we gave it a better name in the web service API, but haven't bothered to rename the attribute itself.
[09:53] <stub> Hmm... we have two poimport connections
[09:53] <jtv> There can be only one.
[09:54] <jtv> Unless one is for the slave.
[09:55] <stub> Nah - one for the lpmain replication set, one for the authdb replication set
[09:55] <stub> Actually, scrub that
[09:55] <jtv> does it make sense for a script like this to talk to the authdb?
[09:55] <danilos> jtv: poimport emails don't go to error-reports anymore, don't they?
[09:56] <jtv> danilos: oh, that must be it.  Don't know why, but I thought that'd been reverted.
[09:56] <jtv> Hi btw :)
[09:56] <danilos> jtv: yeah, hi :)
[09:56] <danilos> jtv: we've got stuff like http://launchpadlibrarian.net/29834164/uK8pt7QInv178EM0SyyuKEuaZai.txt
[09:56] <jtv> danilos: henning's still sick :/
[09:56] <stub> jtv: https://pastebin.canonical.com/20726/ -- same database, same db user, both tables only available in the lpmain replication set.
[09:57] <danilos> jtv: yeah, noticed
[09:57] <jml> hello everyone
[09:57] <jtv> hi jml
[09:58] <danilos> jml: hello
[09:59] <jtv> stub: iirc the script is supposed to lock...
[09:59] <stub> jtv: Looks like approve imports is connecting as the poimport database user?
[09:59] <jml> wuu, all the hip .eu people are around :)
[09:59] <danilos> jtv: poimport logs on devpad have a lot of tracebacks like this
[09:59] <jtv> oh, yes, that could be it.
[09:59] <danilos> jml: all the hip .eu people *and* me too :)
[09:59] <jtv> danilos: where did those logs live again?
[10:00] <danilos> jtv: let me check, I've got a symlink in my devpad $HOME
[10:00] <danilos> jtv: devpad:/srv/launchpad.net-logs/scripts/loganberry
[10:01] <jtv> danilos: thanks
[10:01] <stub> https://bugs.edge.launchpad.net/rosetta/+bug/118633
[10:01] <mup> Bug #118633: pofile import approver should connect as a different database user <fix-it-friday> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/118633>
[10:02] <Makistos> 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] <danilos> jtv: many, many failures like this since the rollout, I can take a look myself
[10:02] <jtv> Makistos: but the "bzr cat" went over http...
[10:02] <jtv> danilos: thanks, then I'll go back to the message-sharing.
[10:03] <Makistos> 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] <jtv> Makistos: glad to hear it.
[10:06] <jtv> stub: so we're getting a lot of nasty import failures that aren't visible on error-reports anymore.  :-(
[10:08] <jml> I'm creating a celebrity team
[10:08] <jml> and I need to put it into the sample data
[10:08] <jml> what should be the PersonCreationRationale for the team owner?
[10:09] <thumper> jml: what celebrity team are you creating?
[10:10] <jml> thumper, techboard
[10:10] <jml> thumper, it's actually already referred to in the code, but not as a celebrity.
[10:10] <thumper> ew
[10:10] <jml> exactly
[10:10] <jml> so I'm fixing that before I proceed to write some tests that actually need to use it
[10:11] <jml> I'm going with PersonCreationRationale.UNKNOWN for the time being
[10:15] <thumper> jml: did you see that mwhudson fixed the setBranch API bug?
[10:16] <jml> thumper, yes, I saw that.
[10:16] <jml> very embarrassing
[10:16] <wgrant> 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] <thumper> jml: sometimes it just takes someone else to look at it
[10:16] <thumper> jml: people can be too close to the code sometimes
[10:17] <thumper> I'm about to propose a branch for merging that _may_ be causing our segfaults
[10:17] <bigjools> 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] <thumper> anyone interested in reviewing it?
[10:17]  * thumper should go to #launchpad-reviews
[10:19] <wgrant> 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] <bigjools> wgrant: don't put security checks in model code
[10:19] <bigjools> bad bad idea
[10:20] <bigjools> security checks go in the ... gasp.... security code :)
[10:21] <wgrant> 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] <wgrant> Although that's already done in syncSource, so I might look there just to see how it's done.
[10:22] <wgrant> Oh, that just works because getPublishedSources is secured.
[10:22] <bigjools> wgrant: it's done in the security adapter
[10:23] <wgrant> bigjools: But it depends on an argument, not the context or method.
[10:23] <wgrant> addArchiveDependency doesn't need to do anything to the dependency argument, so no checks are ever done.
[10:24] <wgrant> So you get nasty nasty bugs like that one in January.
[10:24] <bigjools> if the security adapter is set up properly, it will be okay
[10:24] <bigjools> it's not always possible to make the decision there though
[10:25] <wgrant> I don't think it's possible.
[10:25] <bigjools> upload ACLs being one example
[10:25] <wgrant> Right.
[10:25] <wgrant> How would a security adapter catch this case?
[10:25] <jml> bigjools, :)
[10:25] <bigjools> jml: :D
[10:26] <bigjools> wgrant: you would need lp.Edit on the archive
[10:26] <wgrant> bigjools: You need lp.Edit on the dependent archive to call the function, but not the dependency archive.
[10:26] <wgrant> bigjools: Unless you explicitly check for the permission in addArchiveDependency, which is probably bad.
[10:27] <bigjools> right, you need lp.view on it
[10:27] <bigjools> which will get checked in the sec adapter as soon as you try to reference it
[10:28] <bigjools> write a doc test, you will see (I hope)
[10:31] <thumper> night all
[10:32] <noodles775> Enjoy your evening thumper
[10:32] <jml> thumper, g'night
[10:41] <wgrant> bigjools: Why would the security adapter fail an attempt to reference the archive?
[10:41] <wgrant> Everybody can get the distro of a P3A.
[10:41] <wgrant> And other stuff.
[10:41] <bigjools> hmph
[10:41] <wgrant> And can't I pass a securityproxy'd object around as much as I want?
[10:41] <wgrant> It only cares if I try to access attributes.
[10:42] <bigjools> pesky kids
[10:43] <jml> wgrant, you can pass around a securityproxy'd object as much as you want.
[10:43] <bigjools> that's what he said
[10:43] <bigjools> we could do with views for API calls
[10:43] <wgrant> So if I don't try to do anything to it, I will never die.
[10:43] <wgrant> bigjools: Right.
[10:44] <bigjools> some of the model code takes a user parameter.... ewww
[10:44] <jml> bigjools, it's not the worst thing in the world
[10:44] <jml> bigjools, granted, it's not ideal.
[10:45] <bigjools> well it means that the content class becomes tied to a request
[10:45] <jml> there's a way of saying 'this parameter is the logged-in user' in the API permissions.
[10:45] <jml> bigjools, not necessarily
[10:45] <bigjools> yes, I hate that
[10:45] <bigjools> our content classes are already huge :(
[10:45] <jml> bigjools, ISourcePackage.setBranch for example, the user parameter is the registrant. That's very much a model-level detail.
[10:45] <stub> jtv: Perhaps create a new rationale?
[10:46] <jtv> stub: did you mean jml?
[10:46] <bigjools> jml: that case is fine
[10:46] <stub> I guess the existing ones would be lies then
[10:46] <stub> Yup - jml
[10:46] <jml> stub, UNKNOWN is only a white lie :)
[10:50] <wgrant> bigjools: Anyway, I will go with read-only for now.
[10:51] <bigjools> wgrant: good plan
[10:51] <bigjools> baby steps, and all that
[10:52] <bigjools> jml: btw, the extra info on the pqm landing emails is top drawer
[10:53] <jml> stub, 'make newsampledata' generates a file without a copyright statement, which leads to spurious diffs -- how would I fix that?
[10:54] <jml> bigjools, thanks, but I'm pretty sure that wasn't me :)
[10:54] <bigjools> jml: you're the only representative from the code team who's awake right now :)
[10:55] <jml> :)
[10:58] <jml> 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] <stub> sounds sane
[11:06] <jml> 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] <jtv> danilos, that diff vous wanted: https://code.edge.launchpad.net/~jtv/launchpad/bug-408206/+merge/9579
[11:26] <danilos> jtv: looking
[11:30] <jml> how do I determine which config is being used?
[11:33] <jml> stub, can I get 'make harness' working from launchpad_ftest_playground? I want to use it to add some test sampledata.
[11:33] <wgrant> 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] <bigjools> let me check
[11:34] <stub> jml: make harness LP_DBNAME=launchpad_ftest_playground might work
[11:34] <danilos> jtv: it is simple enough, but without checking that it really helps, I'd really like to avoid asking for a cherrypick
[11:35] <jml> oh huh... 'make harness LPCONFIG=test-playground' is actually mentioned in the README.
[11:36] <stub> My method doesn't work
[11:36] <jml> stub, I'm just verifying my method.
[11:36]  * jml might tweak the README to make this more obvious.
[11:37] <jtv> danilos: we can be pretty sure it helps with the "commit more often" problem.  :-)
[11:37] <jtv> (Which is actually what triggered all the other problems)
[11:39] <danilos> 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] <bigjools> 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] <wgrant> bigjools: I think it's because it has no explicit interface.
[11:40] <jtv> danilos: "make mvo happier" maybe?  :)
[11:40] <danilos> jtv: heh, that is, but only if we can show that it will make him happier :)
[11:40] <bigjools> wgrant: could be, stuff like PublicPersonChoice inherits from ReferenceChoice
[11:40] <jtv> danilos: alternatively, we can tell mvo to STAY AWAY FROM OUR SHINY DATABASE for now.  :-)
[11:40] <wgrant> bigjools: PublicPersonChoice is able to be exported, and it basicall just has the interface set.
[11:40] <wgrant> bigjools: Ah, true, that too.
[11:41] <jtv> (I tried to contact him yesterday, but no luck)
[11:41] <bigjools> wgrant: ok, give PPAChoice a try, but call it ArchiveChoice
[11:41] <danilos> 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] <bigjools> wgrant: actually no, PPAChoice
[11:41] <wgrant> bigjools: Doesn't it actually want to be restricted to PPAs, though?
[11:41] <bigjools> yeah
[11:41] <jtv> 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] <wgrant> Right.
[11:43] <danilos> jtv: well, do you know what's up with staging restores? they are not working either
[11:44] <jtv> 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] <jml> make schema takes way too long :(
[11:52] <stub> 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] <jml> RAOF, hello
[11:54] <danilos> 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] <wgrant> 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] <bigjools> ah!
[11:54] <stub> danilos: Sure.
[11:54] <bigjools> wgrant: I am shocked that you didn't have to deal with circular imports
[11:54] <bigjools> circular import DEATH HELL
[11:54] <wgrant> bigjools: I did.
[11:54] <wgrant> bigjools: But they were easily patched.
[11:55] <jtv> danilos, stub: for now at least, the problems aren't happening because that one large export has been disabled.
[11:55] <bigjools> ah good, sometimes they are not.  I hope you liked my patch_ funcs :)
[11:55] <wgrant> bigjools: They're very useful.
[11:55] <danilos> jtv: right, but we need to re-enable it on staging and test it
[11:55] <RAOF> jml: Hello there.
[11:55] <danilos> jtv: I'll email mvo about it
[11:56] <jtv> danilos: absolutely.  But again, talking about the very short term until we can do that.
[11:56] <bigjools> inline bug commenting ROCKS
[11:57] <danilos> 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] <jtv> danilos: I had already disabled them, so we're in the clear for now.  The last run succeeded.
[11:58] <danilos> jtv: right, but mvo is unaware :) I'll email him (CCing you) and mention the bug we are working on
[11:58] <jtv> danilos: thanks.
[12:19] <jml> bigjools, hi
[12:19] <bigjools> helleau
[12:20] <jml> bigjools, who owns the 'build source packages from branches' task?
[12:20] <bigjools> I don't think anyone does yet
[12:20] <bigjools> Tim and I talked about it
[12:20] <jml> bigjools, cprov, james_w & I specced out a solution at UDS, and I saw you mention that you & Tim talked about it
[12:21] <jml> & mwh @ UDS
[12:21] <bigjools> yeah, it's not as trivial as first thought
[12:21] <bigjools> we need to have a job farm like PPA builders that run VMs that will do the bzr builddeb stage
[12:21] <jml> yes.
[12:21] <jml> that's what we've got on our spec
[12:22] <bigjools> good, so far :)
[12:22] <jml> (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] <jml> it's a very important feature, someone ought to own it, and I don't think I can reasonably volunteer.
[12:24] <jml> although I'd rather like to.
[12:24] <bigjools> jml: I can suggest transferring your notes to a blueprint
[12:25] <jml> bigjools, yeah, that will definitely happen
[12:25] <bigjools> :)
[12:27] <bigjools> jml: the first step is to break the work up into chunks, I think "someone" will be >1 person
[12:27] <jml> bigjools, the project still needs a single person to own it though
[12:28] <bigjools> jml: not necessarily, but yes it does need a single person up front to do the initial breakdown
[12:28] <bigjools> I think most of the work is on the Soyuz side
[12:28] <bigjools> and IS
[12:28] <bigjools> so it might make sense for me to own it
[12:29] <jml> 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] <jml> bigjools, I'll put the spec into a blueprint & send a message to the dev list & your good self.
[12:30] <bigjools> okiedokie, thanks
[12:38] <jml> bigjools, btw, liw just sent a spec / rfc to the launchpad-dev list that you might be interested in.
[12:39] <bigjools> jml: ok, it's not arrived yet but I'll take a butchers in a bit
[12:40]  * jml gains rhyming slang xp
[13:16] <jtv> 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] <stub> 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] <stub> 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] <BjornT> 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] <stub> It might be obvious from the statement logs.
[14:54] <sinzui> noodles775: ping
[15:39] <sinzui> 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] <sinzui> 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] <jtv> 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] <sinzui> jtv: I think you are right
[15:44] <jtv> 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] <sinzui> 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] <beuno> sinzui, on a call for another hour
[15:45] <beuno> but I'll think about it
[15:45] <sinzui> beuno: understood
[15:46] <beuno> sinzui, I suspect we could just find a good context instead
[15:46] <beuno> users have a different perception of context than we do
[15:47] <jtv> sinzui: another question I had... we still have a few isolated actions menu items <boo!> here and there.  If we are to move those inline, do we replicate the permissions requirements in the TAL conditions?
[15:50] <slytherin> does launchpad go through any load testing?
[15:50] <sinzui> jtv: put the links in a menu so that the permissions and text are consistent
[15:50] <jtv> slytherin: mostly by actual use.  Why?
[15:51] <jtv> sinzui: what kind of menu?
[15:51] <slytherin> 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] <sinzui> jtv: If the links act on the context in a global way (change details) then it may go side portlets
[15:51] <jtv> herb, got time for my script run today?  Nag, nag. :-)
[15:51] <jml> any vim users about?
[15:52] <jml> I have an emacs thing that makes it really easy to run 'bzr ls -VR --kind=file --null | xargs -0 grep -In <foo>' in the editor
[15:52] <jtv> mars: see slytherin'
[15:52] <sinzui> 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] <jml> lots of our emacs users love it, since it makes it really easy to find obscure code in launchpad
[15:52] <jtv> s note
[15:52] <jml> how can this be bundled to provide similar joy for vim users
[15:52] <herb> jtv: yes. in a few minutes.
[15:53] <jtv> herb: cool thx
[15:53] <bigjools> jml: what does that do?
[15:53] <jml> bigjools, it greps all of the version controlled files in a branch that aren't binary files
[15:54] <bigjools> jml: I have an LP vim hacking page on the old lp wiki
[15:54] <sinzui> 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] <bigjools> jml: I will migrate it and add your special bzr-fu command
[15:55] <mars> Ursinha, ping, ^ regarding slytherin's question, do you know how far matsubara got with the stress testing tools?
[15:55] <jml> bigjools, cool, thanks.
[15:55] <jml> 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] <jtv> sinzui: will the existing app menus still show up in the new macros then?
[15:56] <jtv> sinzui: sorry, nav menus.
[15:57] <sinzui> No, beuno hates that design.
[15:58]  * jtv wishes UI design would stop affecting the code :-)
[15:58] <sinzui> 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] <beuno> jtv, we all do  ;)
[15:58] <jtv> beuno: stay out of this.  You're the one causing this pain.  :-P
[15:59] <jtv> sinzui: so what did you do to make the nav menu show up in the actual page again?
[16:00] <bigjools> jml: I'd rather not look at *any* .el file ;)
[16:00] <sinzui> 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] <jml> bigjools, :)
[16:01] <jml> gary_poster, I just filed https://bugs.edge.launchpad.net/launchpad-foundations/+bug/408897 -- maybe it's not appropriate
[16:01] <mup> Bug #408897: Use latest zope.testing <Launchpad Foundations:New> <https://launchpad.net/bugs/408897>
[16:01] <bigjools> for reference: https://dev.launchpad.net/UltimateVimPythonSetup
[16:01] <Ursinha> mars: actually that was me, I was working with FunkLoad
[16:01] <jtv> sinzui: ah, I just read about that transformation.
[16:01] <Ursinha> me and stub
[16:01] <sinzui> 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] <jml> (but I just came across a corker of a testrunner bug while helping cjwatson with his python2.5-based Launchpad development)
[16:02] <jtv> sinzui: cool, examples are good.  Thanks.
[16:02] <bigjools> jml: have you seen ack-grep BTW?
[16:02] <jml> bigjools, the name rings a bell.
[16:02] <bigjools> it's written in perl but I won't hold that against it (too much)
[16:02] <jtv> 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] <mars> Ursinha, slytherin was just wondering if we wanted to try out jmeter, as he has packaged it for the base distro
[16:03] <sinzui> 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] <sinzui> 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] <gary_poster> jml: ok, cool.  sorry for the pain.  the zope buildout branch is next in line for me to return to it. :-) :-/
[16:05] <jtv> 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] <jml> gary_poster, no worries at all. just wanted to know, since a lot of this python upgrade stuff is still fairly opaque.
[16:06] <bigjools> jml: I have no idea what that dot hell file is doing, I will need help to convert to a vim macro :(
[16:06] <gary_poster> 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] <jtv> 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] <andrea-bs> 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] <mup> Bug #315858: It's not obvious how to subscribe to a mailing list <mailing-lists> <registry-people> <ui> <Launchpad Registry:Fix Released by sinzui> <https://launchpad.net/bugs/315858>
[16:08] <cjwatson> 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] <bigjools> jml: does emacs have python bindings?
[16:08] <sinzui> 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] <maxb> 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] <sinzui> 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] <cjwatson> maxb: I'm using your stuff
[16:09] <maxb> yay :-)
[16:10] <cjwatson> well, more or less, it's been a little while since I synced
[16:10] <cjwatson> *please* get that merged if at all possible :-)
[16:10] <maxb> I still haven't managed to convince the testsuite to run all the way through
[16:10] <cjwatson> I'm not even trying
[16:10] <gary_poster> maxb: you don't have to get the test suite to run all the way through in Py 2.5 to commit
[16:11] <gary_poster> maxb: you have to get it to run in 2.4
[16:11] <gary_poster> so maybe that would make it easier to make incremental checkins?
[16:11] <gary_poster> (s/commit/merge)
[16:11] <sinzui> 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] <maxb> I really ought to get myself a working 2.4 environment. I don't have one at the moment.
[16:12] <gary_poster> maxb: sounds like a plan ;-)
[16:13] <cjwatson> it's a right pain to do in karmic. I tried briefly but life is too short.
[16:13] <herb> jtv: devpad:/home/herb/jtv.out
[16:13] <cjwatson> (chroots are of course possible)
[16:13] <jtv> herb: great, thanks.
[16:14] <gary_poster> cjwatson: granted :-/
[16:14] <cjwatson> also, OMG distroseries.createUploadedSourcePackageRelease is a painful interface
[16:14] <gary_poster> heh
[16:14] <jtv> herb: this time I caught the bugger with an explicit sync, just what I needed to pinpoint it.
[16:14] <andrea-bs> sinzui, I see that the situation is a bit complex :) Thank you for the clarification.
[16:17] <sinzui> 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] <andrea-bs> sinzui, I know: I have reported a bug describing the same situation
[16:20] <sinzui> 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] <salgado> beuno, you don't have a mockup of the project/distro page, like the one you have for the person page?
[16:30] <andrea-bs> 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] <andrea-bs> become a member).
[16:31] <sinzui> 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] <sinzui> 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] <sinzui> andrea-bs: and any person should be able to receive list mail even if he is not a member of a team
[16:42] <andrea-bs> 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] <andrea-bs> do this twice and so on...
[16:42] <andrea-bs> 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] <mars> hmm.  so enforcing the communications team split would in effect be encoding policy into Launchpad
[16:43] <mars> and project teams will ask questions when that policy is foisted upon them
[16:44] <mars> andrea-bs, I agree with that last point.  It would be really odd.
[16:44] <mars> and onerous to explain
[16:44] <sinzui> andrea-bs: In the past we said DO NOT JOIN A TEAM. being a member of team should never be required to contribute. Teams are meant to be ACL. This was stupid. Every person on the planet knows that a team is a group of people with a common goal and they communicate.
[16:44]  * jml is back
[16:45] <jml> gary_poster, whether we plan to do so, I guess.
[16:45] <mars> sinzui, :)
[16:45] <jml> gary_poster, and also, I think that in an ideal world, there'd be a tag called python-upgrade and a lot of bugs filed against it.
[16:45] <sinzui> andrea-bs: So team owers encourages users to join teams, but then discovered the members had more power than they should
[16:45] <jml> bigjools, emacs has an extension that lets you use python bindings
[16:45] <jml> bigjools, by default, it only has elisp bindings :)
[16:46] <sinzui> andrea-bs: It might be helpful if we rethink what we did. Launchpad created control groups, and called them teams. A few years later, it created mailing lists, and called the teams. Maybe we do not need teams
[16:46] <mars> sinzui, why not go with "teams to communicate", "capabilities for rights"?
[16:46] <jml> maxb, I started this patch, btw, http://paste.ubuntu.com/247305/
[16:47] <jml> maxb, I had to do a similar thing to get 'trial' working on python 2.[3456]
[16:47] <mars> sinzui, so a team is a social structure
[16:47] <maxb> jml: aha, I didn't attempt a [456] solution on that one yet
[16:47] <jml> maxb, if my calculations are correct, it'll let TestCase work on Python 2.4 and 2.5.
[16:47] <mars> sinzui, and capabilities (or groups with roles) codify the governance structure
[16:48] <maxb> It's a bit worrying that we have to dig into double-underscore attributes at all
[16:48] <sinzui> mars: That has been discussed. I want the team to be social, I want it to behave as users think of teams. I want to extract the ACL rules to a separate object to that is clear what the purpose is
[16:48] <jml> (but I've bumped into some zope.testing bugs now)
[16:48] <mars> sinzui, big +1
[16:48] <jml> maxb, it's not our fault the unittest module sucks.
[16:49] <maxb> jml: Why are you using getattr? Wouldn't direct attribute access work just the same?
[16:49] <mars> sinzui, you'll have to answer the inevitable question, "Can't I give every other member the capability to do X?"
[16:49] <danilos> rockstar, abentley, jml: where can we see if there are any problems with rosetta upload bzr job?
[16:49] <mars> sinzui, but that is easy if you have the two objects clearly separated
[16:49] <mars> s/objects/concepts/
[16:49] <abentley> danilos: What kind of problems?  Oopses?
[16:50] <danilos> abentley: I don't know, I am suspecting some OOPSes or exceptions, nothing is happening when it should, and I want to see why
[16:50] <beuno> salgado, I do for project
[16:50] <beuno> it's what sinzui is working on AFAIK
[16:50] <jml> maxb, because the patch isn't finished yet :)
[16:50] <maxb> heh
[16:50] <sinzui> mars: I have recently been thinking about implementing roles in launchpad (owner, driver) as an implicit team, you are always adding to it (not assigning it). you cannot see it. It is there. Just like every project automatically gets a trunk series.
[16:51] <abentley> danilos: I would expect to see them at devpad:/x/launchpad.net-logs/scripts/crowberry but there aren't any.
[16:51] <jml> maxb, anyway, I'd personally be very happy to review & land patches of about that size that help with python 2.5 support
[16:51] <gary_poster> jml: we do plan to do it--I'm in the middle of it but have had umpteen million things inbetween start and finish.  And +1 on tag, sounds reasonable.
[16:51] <jml> since I'm running karmic & developing inside a chroot atm
[16:51] <jml> gary_poster, I know the feeling :(
[16:51] <mars> sinzui, ah, interesting.  Nice abstraction.
[16:51] <sinzui> mars: two objects is my desire. I want to include it in my 4.0 goals, I also want subscriptions simplified. It should not be used  for ACL
[16:52] <jml> gary_poster, sorry for the hassling. I'll make the tag now and encourage cjwatson, maxb & others to start filing bugs :)
[16:52] <gary_poster> jml: no apologies needed :-)  cool thanks
[16:52] <danilos> abentley: how often is that refreshed, if you know?
[16:53] <maxb> jml: I need to get myself a chroot set up so I can validate that I haven't broken 2.4 - is it just a plain debootstrap of jaunty, apt-get install launchpad-dependencies, and rocketfuel-setup inside the chroot?
[16:53] <abentley> danilos: Every 10 minutes, I believe.  Is this on production or staging?
[16:53] <danilos> abentley: production
[16:53] <salgado> beuno, right, I just had a call with him and he'll send me some screenshots. thanks
[16:53] <jml> maxb, I'm running a hardy chroot, pretty much a plain debootstrap
[16:53] <jml> maxb, but I guess jaunty would work fine
[16:54] <abentley> danilos: Best to ask a LOSA, I think.
[16:54] <beuno> sinzui, let me know if you need a call  to unblock you on anything
[16:54] <beuno> noodles775, ditto
[16:54] <danilos> abentley: sure, thanks
[16:54] <beuno> bigjools, looking at your mockups
[16:54] <jml> maxb, I think I'm going to abandon that patch I pasted you, since I really really want to get the official package branch permission thing up and running
[16:55] <maxb> jml: ok then, I'll merge it into my branch
[16:55] <jml> maxb, cool
[16:55] <bigjools> beuno: jolly good
[16:55] <jml> maxb, again, let me encourage you to land lots of small changes that get us incrementally closer to 2.5.
[16:55] <gary_poster> +1
[16:55] <jml> maxb, I'll review them faster than you can say Jack Robinson
[16:55] <gary_poster> Jack Robinson
[16:56] <maxb> I think you have to say it after a review branch exists :-)
[16:56] <jml> yeah
[16:56] <gary_poster> oh darn
[16:56] <jml> also, you have to say it, and then mail me a cassette with the recording of you saying it.
[16:56] <gary_poster> lol
[16:58] <andrea-bs> sinzui, I like your idea, but without a team, how can somebody *easily* have permissions, for example, to push to a branch? I mean: clicking on "Join" and asking for a team admin to approve your membership is quite simple. If the team admin also have to give you the access to a branch, things get more complicated, don't you think?
[17:00] <sinzui1> Sorry beuno, andrea-bs, mars: Firefox is killing X. I cannot see your messages
[17:00]  * sinzui1 is trying a different computer
[17:02] <jml> leonardr, hi
[17:03] <jml> leonardr, I have a cred-cache branch for launchpadlib that we talked about some time ago. You suggested that I ping you about it after a while.
[17:03]  * jml loves being in a convenient timezone
[17:04] <leonardr> jml: there's a slight chance someone else wrote and landed your branch
[17:04] <leonardr> how long ago are we talking about?
[17:04] <jml> maybe two months
[17:05] <jml> nope
[17:05] <jml> the merge proposal was requested on  2009-06-18
[17:05] <jml> leonardr, https://code.edge.launchpad.net/~jml/launchpadlib/cred-cache/+merge/7608
[17:07] <leonardr> jml, take a look at Launchpad.login_with()?
[17:07] <leonardr> no, that already exists in your branch, so you must be doing something different...
[17:08] <jml> leonardr, I've added a convenience function that does this:
[17:08] <jml> - look for cached credentials in a deterministic location
[17:08] <jml> - if they exist, log in with those
[17:08] <jml> - if they don't exist, get a new set of credentials from the user and store them in a deterministic location
[17:08] <beuno> sinzui, I just said to let me know if you need a call to unblock you on anything
[17:10] <sinzui2> beuno: I am preparing screencaps of the project page now
[17:12] <beuno> sounds good
[17:13] <leonardr> jml: i believe login_with() does the same thing. take a look and see if you agree. there were a lot of reviewed but unmerged launchpadlib branches the last couple months due to the lazr refactoring
[17:14] <andrea-bs> sinzui, here's my last message: I like your idea, but without a team, how can somebody *easily* have permissions, for example, to push to a branch? I mean: clicking on "Join" and asking for a team admin to approve your membership is quite simple. If the team admin also have to give you the access to a branch, things get more complicated, don't you think?
[17:15] <sinzui> andrea-bs: right. This is great example of why teams are really needed
[17:17] <sinzui> andrea-bs: This kind of team may also want a list, in which case we the owner should be warned that  all members will get mail. if this is what the owner intends, continue, otherwise create a list.
[17:17] <jml> leonardr, the code looks the same. I'll double check with a simple experimental script
[17:18] <leonardr> jml, great, sorry for the duplication
[17:19] <jml> leonardr, no worries at all. :)
[17:19] <jml> cool. I'll abandon the branch and delete an item or so from my todo lists :)
[17:21] <jml> leonardr, while I have you on the line, so to speak, can you take a look at bug 376284
[17:21] <mup> Bug #376284: Ability to remove branches using the API <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/376284>
[17:21] <jml> leonardr, I made an extremely vague comment at the bottom. ISTR that DELETE support was only recently added to launchpadlib?
[17:22] <leonardr> jml, i'll look, but i think the only thing you can delete is file uploads
[17:23] <jml> leonardr, but could we expose a DELETE thing for branches?
[17:23] <jml> in fact, I'll let you just comment on the bug, rather than reply to my rambling questions.
[17:24] <leonardr> jml, sure
[17:29] <sinzui> beuno: can you comment on https://bugs.edge.launchpad.net/launchpad-registry/+bug/405916 today. I have screencaps and issues for you to think about
[17:29] <mup> Bug #405916: Update project page to UI 3.0 <story-ui-3> <Launchpad Registry:In Progress by sinzui> <https://launchpad.net/bugs/405916>
[17:35] <leonardr> jml, commented
[17:35] <beuno> sinzui, sure, right after lunch
[17:38] <jml> leonardr, thanks.
[18:02] <beuno-lunch> bigjools, the second option is looking better
[18:03] <beuno-lunch> bigjools, didn't we find a different way to display in what archs it was built?
[18:03] <bigjools> beuno-lunch: not that I know of
[18:03] <beuno-lunch> columns seems...  odd and not very scalable?
[18:04] <beuno-lunch> bigjools, could we hide the bits of information that don't have a value?
[18:04] <beuno-lunch> "Suggests:", for example
[18:04] <bigjools> beuno-lunch: yes, I planned on that, it's just there for the sake of the mockup right now
[18:05] <bigjools> beuno-lunch: but the table seems perfect to show what we need, although it have a lot of columns in production
[18:05] <bigjools> s/it/it will/
[18:12] <mrevell> see you tomorrow guys
[18:33] <EdwinGrubbs> sinzui: ping
[18:59] <EdwinGrubbs> beuno-lunch: ping
[19:11] <beuno> Edwin-lunch, hi
[19:25] <salgado> sinzui, what's the rule for the usage of the top-portlet class?  I thought there should be only one element with that class in a page but I see 3 in the new project page on your branch
[19:26] <sinzui> salgado: It i the top of a column. It just defines whitespace rules and does not have a top-border. Lots of simple pages like edit forms do not require it
[19:28] <dobey> hey all
[19:29] <dobey> is there a public project on lp that would be an appropriate place to stick some useful client tools that use the API to do things?
[19:30] <salgado> sinzui, I see, thanks
[19:30] <beuno> leonardr, ^
[19:31] <leonardr> dobey: we usually put those scripts in launchpadlib/samples
[19:37] <EdwinGrubbs> beuno: you mentioned that the latest design has a place for global actions. Is that above the sidebar as shown in the mockups. It seems kinda strange to not be in the sidebar.
[19:37] <EdwinGrubbs> sinzui: ping
[19:37] <sinzui> Hi EdwinGrubbs
[19:38] <EdwinGrubbs> sinzui: meeting?
[19:39] <beuno> EdwinGrubbs, sinzui has the mockup
[19:39] <beuno> it's in a portlet on the right
[19:39] <sinzui> EdwinGrubbs: yes. we should talk. And I have two images for you
[19:41] <sinzui> EdwinGrubbs: You have mail
[20:10] <salgado> sinzui, is the 'Mentoring' link gone from the new project page?  if so, should it not exist in the new project-group page as well?
[20:11] <sinzui> salgado: I am infavour of trying to make mentoring work. Recent discussion by others imply we should abandon the feature
[20:12] <sinzui> salgado:  I did not realise that I lost mentoring in the product-index draft I did
[20:12]  * sinzui thinks beuno would approve of that
[20:13] <salgado> heh
[20:14] <salgado> consider it gone from the projectgroup page too, then. :)
[20:14] <beuno> \o/
[20:14] <sinzui> beuno: salgado: if we drop mentoring without trying to fix it, users will point to it as an example of something we built, never dogfooded, and never cared about.
[20:14]  * beuno high-fives salgado 
[20:14] <beuno> sinzui, and it will be true
[20:14] <beuno> I'm all for fixing it, but I'd only leave it on there if we have a concrete plan to do so
[20:15] <sinzui> well I agree with that, and the best that can be said is that it is a 4.0 candidate.
[20:15] <sinzui> beuno: salgado: let's ignore the feature
[20:15] <beuno> :)
[20:16] <sinzui> As I think about this. we have ignored bounties long enough. When are we removing the code?
[20:16] <beuno> I don't like missleading users into thinking they can do something they really can't
[20:16]  * sinzui knows there are hacks in the test suite to ensure the rotting code does not break other tests
[20:25] <salgado> sinzui, I see some portlets with class="yui-u portlet" and others with just class="yui-g" in product-index.pt, but I can't see any difference between them... are both meant to be used? if so, when?
[20:25] <sinzui> hmm
[20:25] <sinzui> I think I need to update the wiki with your observation
[20:26] <salgado> actually, it's only the series-and-milestones portlet that uses "yui-u portlet"
[20:26] <sinzui> yui-g created columns, yui-u is a column. The first column is 'yui-u first'
[20:26] <beuno> salgado, has someone told you about the navigation work we're going to be doing together?
[20:28] <sinzui> salgado: 'yui-u portlet' makes a column and presents it as a portlet, but I discovered that yui-u and first must always be on the same div, which does not work for how we embed portlets
[20:28] <salgado> sinzui, sorry, I meant that some have "yui-u portlet" and others have just "yui-u".  your email mentions the distinction between yui-u and yui-g
[20:28] <sinzui> salgado: so I decided that our portlet will have the portlet class, and the calling template will wrap the portlet in a yui-u div (optionally defining the first one)
[20:28] <salgado> (man, how can it be so painful to type yui.  is it just me?)
[20:29] <beuno> sinzui, the ffedback I need to give you is in bug 405916, right?
[20:29] <mup> Bug #405916: Update project page to UI 3.0 <story-ui-3> <Launchpad Registry:In Progress by sinzui> <https://launchpad.net/bugs/405916>
[20:29] <salgado> beuno, nope, nobody mentioned it to me. when are we starting?
[20:29] <sinzui> salgado: I think I need to revised my product-index page to never mix 'portlet' with 'yui-u' since it often breaks
[20:30]  * sinzui will try to explain the problem better on the wiki page
[20:30] <beuno> salgado, as soon as I manage to focus for 1 hour straight. The gist of it making breadcrumbs more detailed, so we need specific pages to be able to generate a path we decided on
[20:30] <sinzui> beuno: yes, that one.
[20:30] <beuno> sinzui, ok, it's almost next on my list then
[20:31] <beuno> I'm loosing track of the balls I have in the air  :)
[20:32]  * sinzui is a day behind on email because he needs to get UI 3.0 example to everyone, which mean actually creating what ahs never been done before
[20:49] <beuno> sinzui, email is for whimps
[20:49] <beuno> if people really want to talk to you, they will go meet you in person, like I did
[20:50] <beuno> sinzui, also, the new project pages look sweet
[20:51] <beuno> even more so when they're busy projects
[20:51] <beuno> what do you think about not showing the sections that have no data?
[20:51] <beuno> I talked about this via email with EdwinGrubbs
[20:52] <sinzui> I have mixed feelings. I am torn between the bugs reported that something is not obvious because we not not clearly state: There is not mailing list, there are not branches, there are no bugs, and the desire to show only what I want to know
[20:52] <beuno> sinzui, in some cases, sure
[20:53] <beuno> but top contributors, latest questions, events, etc
[20:53] <beuno> they add no value
[20:53] <sinzui> beuno: We need to be consistent so that I can mark bugs WONTFIX
[20:54] <sinzui> beuno: and without those sections users do not know what will happen when they appear
[20:54] <beuno> sinzui, only show "this does not exist" for objects that can be added/created?
[20:54] <sinzui> I can add a create FAQ
[20:55] <sinzui> considering there is only one link on the site to do this...this would double the number of places
[20:55]  * sinzui like the rule and will use it to close some bugs
[20:57]  * beuno is practicing his create-rules-on-the-fly skills
[21:01] <beuno> BjornT, inline comenting is SO much nicer
[21:01] <beuno> requests seem to take a long time to get back
[21:01] <beuno> I wonde rwhy
[21:07] <mars> beuno, how many MS does it take?
[21:07] <mars> milliseconds
[21:08] <beuno> mars, I probably waited for 5 or 6 seconds
[21:08] <sinzui> beuno: I think yui-u and yui-u first will break with optional content
[21:08] <mars> I'm curious, because one of the big negatives to adopting AJAX was the server response time
[21:08] <mars> 5 to 6 seconds?  :(
[21:09] <beuno> yeah, maybe we're under some stress in teh servers, I don't know. Will continue to observe
[21:09] <mars> 5000ms ! <= 450ms
[21:09] <beuno> mars, try it out, let me know how it goes  :)
[21:09] <sinzui> beuno: when sprints appeared on it own in my page, it was positioned to the right. I think every portlet that has a first must be guaranteed to render
[21:09] <beuno> sinzui, so we can't float them to the left?
[21:10] <sinzui> well that is what first is doing. but the way YUI-grid is working the calling template and the portlet do not know what they are doing. This was a big layout problem for me
[21:11]  * beuno tries to decide if he will let technology take over UI or not
[21:11] <mars> beuno, which bug were you using?
[21:12] <sinzui> beuno: I considered the option of laying out the page from right to left. Then I do not need first, I just need to to know the page portlet calls are the reverse of what you see in the page
[21:12] <beuno> mars, https://launchpad.net/bugs/405916
[21:12] <mup> Bug #405916: Update project page to UI 3.0 <story-ui-3> <Launchpad Registry:In Progress by sinzui> <https://launchpad.net/bugs/405916>
[21:12] <beuno> sinzui, that sounds like a solution as well
[21:13] <sinzui> beuno: the approach is awkward, but guaranteed to scale with a bug page with lots of shared portlets
[21:14] <beuno> sinzui, it solves my problem, so that's as far as I can approve of that
[21:15] <sinzui> just remember that the order you see in the page is not what you see in the code
[21:15] <beuno> that's going to cause a few WTFs
[21:16] <beuno> but just once  :)
[21:17] <mars> beuno, have inline comments landed on staging yet?
[21:18] <beuno> mars, no  :*
[21:18] <beuno> :(
[21:18] <beuno> didn't mean to kiss you  :)
[21:18] <mars> urgh
[21:19] <mars> Have to keep in mind to test the response times later on
[21:20] <beuno> if time where free
[21:20] <beuno> we would of gotten that profile information coded into the widgets
[21:20] <beuno> and would have these amazing graphs
[21:20] <beuno> and flying cars
[21:22] <dobey> we have flying cars
[21:23] <rockstar> dobey, just because you drive fast doesn't mean your car is flying.
[21:24] <dobey> rockstar: actually, at speed one of my cars builds up enough pressure under the hood, that it creates lift
[21:24] <dobey> rockstar: but i was talking about http://www.terrafugia.com
[21:25] <dobey> or http://www.moller.com/
[21:33] <beuno> mars, see #launchpad-cde
[21:35] <rockstar> beuno, http://devpad.canonical.com/~rockstar/answers-portlets.png - http://devpad.canonical.com/~rockstar/answers-portlets-after.png
[21:35]  * beuno looks
[21:35] <rockstar> beuno, does that look better?  I think it does, but I'm also not the UI dude.
[21:35] <rockstar> I think we need to do our best to not cram stuff together.
[21:36] <beuno> rockstar, it does. It makes me wonder 2 things:
[21:36]  * rockstar listens intently
[21:36] <beuno> 1) Should we be cramming that in a portlet?
[21:36] <beuno> 2) Should the information be bold instead of the labels?
[21:37] <rockstar> To 1), I say yes, because it's meta information, and has no bearing on the actual page.  I'd like the branch page to take note from it.
[21:38] <rockstar> I think the answer pages are about questions and answers, and everything else is extra.
[21:39] <rockstar> To 2), I think it's good the way it is.  Originally I thought of changing font sizes, but I read a book that says that's bad, and I believe everything I read.
[21:42] <beuno> rockstar, it's better, but it feels crammed, and hard to read
[21:42] <beuno> I'm trying to think of what would improve that
[21:42] <beuno> when you say it has no bearing with the actual page
[21:42] <rockstar> Yeah, it does feel crammed.  That's why I spaced it out a bit.
[21:42] <beuno> what page is it?
[21:43] <rockstar> The answers index page.
[21:45] <beuno> rockstar, some of it does feel as part of the page
[21:45] <beuno> you could split this out
[21:45] <beuno> you could display who filed it and when
[21:45] <beuno> just like we do on bugs/blueprints/code
[21:46] <beuno> that removes 2 items from there
[21:46] <rockstar> Well, now that I'm looking at it, that's already there.
[21:46] <beuno> status and asignee seem important, as who solved it and when
[21:46] <rockstar> Also, why is there a "Last query" field.
[21:46] <beuno> so that leaves a small portlet, which shouldn't feel crammed anymore
[21:46] <beuno> sounds crazy
[21:47] <beuno> probably "last time something happened"?
[21:47] <rockstar> Wait, lemme screenshot the whole page for you really quick.
[21:47] <rockstar> http://devpad.canonical.com/~rockstar/answers-page.png
[21:48] <rockstar> We might do better on the phone for this actually.  Is that okay with youL
[21:48] <rockstar> beuno, ^^
[21:48]  * beuno looks
[21:48] <beuno> sure
[21:49] <beuno> let me find headphones
[21:51] <beuno> rockstar, almost ready
[21:54] <Ursinha> bigjools, are you there?
[22:07] <thumper> morning
[22:07] <thumper> I have to drop the car off for new brake pads
[22:07] <thumper> I shouldn't be too long
[22:07] <thumper> bbs
[22:09] <mwhudson> good morning
[22:11] <al-maisan_> Hello mwhudson and thumper!
[22:11] <rockstar> al-maisan_, go to bed.  :)
[22:11] <al-maisan_> rockstar: aye! :)
[22:31] <jml> mwhudson, thumper: good morning
[22:31] <mwhudson> jml: yo
[22:32] <jml> mwhudson, mind if I skype you quickly to catch up on some stuff I missed last week?
[22:32] <mwhudson> jml: go for it
[22:53] <thumper> back
[22:54] <rockstar> sinzui, I have a CSS question for you.
[23:00] <thumper> jml: you areound for the standup?
[23:00] <sinzui> rockstar: sorry, I wasn't ignoring you, I thought you were going to ask the question in the next minute
[23:01] <rockstar> sinzui, oh, I was trying to do a content ping there.  :)
[23:01] <jml> thumper: sure, I guess.
[23:01] <rockstar> sinzui, so, I'm messing around with the subscribers portlet, and I need to make the h2 in the portlets have the underline and bold, like the subscribers portlets for bugs and branches.
[23:02] <thumper> rockstar: skype doesn't like you this morning
[23:02] <rockstar> sinzui, my understanding is that you are currently the CSS gatekeeper, so I wondered if you had done something already, or could suggest a place for me to put it.
[23:02] <rockstar> thumper, really?
[23:02] <jml> thumper: do it!
[23:03] <thumper> jml: I'm trying
[23:03] <sinzui> rockstar: I was not aware that I am, but I am happy to advise. My principle concern is reusablity. So I hope that every class added will be used by more than one app.
[23:03] <jml> thumper: the call drop
[23:03] <jml> fate hates us.
[23:03] <thumper> jml: np
[23:03] <jml> I'll read the minutes :)
[23:03] <barry> gary_poster: ping
[23:03] <thumper> jml: ok
[23:03] <gary_poster> barry: swish!
[23:04] <rockstar> sinzui, okay, so maybe I should coordinate with thumper, since he'll be the next fool to mess with subscribers.
[23:04] <sinzui> rockstar: <h2> in the side portlets are grey in the design. why is it underlined?
[23:04] <barry> gary_poster: hi.  i'm not really here <wink> but i have a quick question for you.  i'm getting a test failure in lazr.restful and was wondering if you could verify.
[23:04] <rockstar> Well, beuno said he liked the way they were, and the branch page has them underlined.
[23:06] <sinzui> rockstar: what happens when they are clicked? How do other developer know that their <h2> must be underlined.
[23:07] <sinzui> rockstar: I think I can ask this differently. If this is special, what is that reason and how do we ensure eveything like it do also treated the same way so that engineers and users understand the rule
[23:07] <rockstar> sinzui, well, this is strictly for subscribers.
[23:08] <sinzui> rockstar: because there are direct and indirect subscriptions?
[23:08] <rockstar> sinzui, kinda, but not really.
[23:09] <sinzui> oh!
[23:09] <rockstar> If there's a better way we can standardize, I'm all for it.  I was just instructed to make answers subscriptions look like everyone else's subscriptions.
[23:09] <sinzui> sorry, I just looked at the current page. it has a rule under the heading,
[23:10] <sinzui> I think the grey <h2> should have the same bold ass all side portlet headings.
[23:11] <sinzui> rockstar: I think all need the rule or none do. I like the rule
[23:12] <rockstar> sinzui, I do as well.  Where should I put the css for that?
[23:13] <wgrant> Can somebody please ec2test lp:~wgrant/launchpad/export-archive-dependencies for me?
[23:13] <rockstar> wgrant, I can.
[23:13] <sinzui> There is already a css rule for .side h2. We can add an bottom border. I think that will look odd in the design that beuno approved for the project page though
[23:13]  * sinzui tries it right now
[23:14] <wgrant> rockstar: Thanks.
[23:14] <rockstar> wgrant, is it approved for landing?
[23:14] <wgrant> rockstar: It's not. Should it be?
[23:15] <wgrant> None of those with whom I discussed it are around now.
[23:15] <rockstar> wgrant, no, it doesn't need to be.
[23:15] <rockstar> wgrant, it's just possible for me to have ec2 submit to pqm when done.
[23:15] <wgrant> rockstar: Ah.
[23:20] <sinzui> rockstar: beuno: compare https://devpad.canonical.com/~curtis/product/firefox-3.0.png with https://devpad.canonical.com/~curtis/product/h2-test.png All I did was add the old side portlet <h2> 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 <h2>?
[23:55] <thumper> phew
[23:55] <thumper> finally
[23:56] <thumper> inbox has no unread emails