=== ajmitch_ is now known as ajmitch === niemeyer_ [n=niemeyer@200.138.34.5] has joined #launchpad [12:52] Who is the expert on user accounts? [12:54] jblack: How do you mean? What do you want to know? [12:54] > (By the way, is there any way to change my username to 'jam' or [12:54] > 'jameinel' instead of the full john@arbash-meinel.com?) [12:55] There's a few things here. Launchpad names don't contain "@". [12:56] But it's possible to login with your email address rather than your username, Launchpad's happy either way. [12:56] He probably thinks this because the login box accepts "john@arbash-meinel.com". [12:56] Oh, hmm, maybe launchpad itself only takes email address. [12:57] Ah, yeah, launchpad.net only allows email addresses for logging in. [12:58] We could change that, although with browser form autocompletion, it's generally not a big issue. [12:59] (and existing email addresses have the advantage of being easier to remember than yet another login) [01:01] So, he could file a bug on Launchpad asking for it to be logging in by nickname to be allowed, rather than just email address. [01:02] I'm personally a little hesistant to support multiple ways of doing things, it can make things less usuable rather than more. [01:04] Since launchpad doesn't have a habit of allowing long-lived cookies, if his browser doesn't support saving form data then see where he could get annoyed. *Not that he is [01:05] Well, cookie lifetime is about to get bumped up to 60 days, I think. [01:05] 60 days may or may not be reasonable. I think its currently set for browser close. [01:06] It's currently about 12 hours, iirc. [01:06] We recently moved the session data into postgres so that it would be persistent across webapp restarts and the like. [01:06] You look correct. I just double checked. [01:07] "Don't oversleep! You could have to log in again!" [01:09] Heh. === mpt [n=mpt@202.53.187.9] has joined #launchpad [01:19] bradb: ping [01:21] jblack, he's not here === mpt [n=mpt@202.53.187.9] has joined #launchpad === mpt [n=mpt@202.53.187.9] has joined #launchpad [03:19] Merge to devel/launchpad/: Remove an unnecessary LEFT OUTER JOIN from a query generated by the ValidPersonOrTeam vocabulary. r=kiko (r3028: Guilherme Salgado) === Kinnison [n=dsilvers@haddenham.pepperfish.net] has joined #launchpad [03:44] lifeless: Is it ok for me to make multiple cherry picks in bzr, followed by a single commit? Or should I still merge, commit, merge, commit, merge, commit? [03:47] bzr on balleny seems much, much faster [03:51] stub: yes, I updated the snapshot [03:51] late last week [03:52] uhm, we dont record cherry picks as such at the moment [03:52] so, do whatever is easiest. [03:52] Doesn't really matter now that commit is quick ;) [03:57] Does IO wait time (as reported by top) mean *just* sucking stuff from disk, or does it measure more than that under Ubuntu? [03:58] c/sucking/sucking and stuffing/ === mpt [n=mpt@219-89-151-25.jetstart.xtra.co.nz] has joined #launchpad === Burgundavia [n=corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad [04:20] you mean the figure up the top ? [04:24] Yup. The CPU percentage [04:28] IIRC the [04:28] percentage of processes blocked on IO [04:28] or something like [04:28] where IO != disk alone === fabbione looks around for somebody to kill [04:31] thats pretty harsh [04:31] Launchpad is offline at the moment for maintenance. It should be back, better than ever, soon. Thanks for your patience. [04:31] its being upgraded [04:31] should tell me that after i login [04:31] HOW?! [04:31] before i enter and change stuff? [04:31] and push the "commit changes" button? [04:32] its a web app - it wasn't offline before, now it is [04:32] WEEEEEE [04:32] we can't tell how many requests are outstanding [04:32] you mean you just started the upgrade in the last 2 minutes? [04:32] yes [04:32] crap === fabbione wants to taste some blood :D [04:33] ok how long is going to take? [04:33] stub: how long is the upgrade looking ? [04:34] 20 minutes ? [04:34] lifeless: Done [04:34] stub: sweet. fabbione ^^ === fabbione pats stub [04:35] if we had ultra-persistent logins implemented, fabbione could now just click "Reload" [04:35] to resubmit the form [04:35] I can get the downtime down to about 5 minutes for most upgrades now ;) [04:35] mpt: that did work.. or it seems so [04:35] stub: slick [04:35] stub: benefits of automation ? [04:36] lifeless: Benefits of planning, multiple app servers, and a more intelligent full text index rebuilder [04:36] stub, so "soon" can be changed back to "in a few minutes"? [04:36] I'll be updating the rollout docs for 8.0 and the procedures [04:36] fabbione, cool [04:36] mpt: I can't guarentee that ;) Some upgrades will still take a while depending on how much database stuff needs to happen [04:37] ok, how long is "a while"? :-) Within an hour? === stub goes to upgrade the second app server [04:39] mpt: It really depends. Worst case would be about 1.5 hours I *think*, but I won't know for sure until we actually do that case on this hardware. If we have major data migration work to do, it can still be longer. We had one rollout where it took the scripts about 4 hours to run. [04:39] mpt: We do have ultra persistent logins [04:40] There is a bug open on that, because they are too persistent for people using shared computers [04:40] 'logout' ? [04:41] was that introduced recently? [04:41] yes [04:42] mpt: We have had persistent logins for a week or two (persistent cookies, and the credentials remembered over server restarts). They used to time out after 12 hours, but this roll out bumped that up to 60 days. [04:43] So if there are any more reports about people getting logged out, either their browser or proxies are screwing them over or we have an undiscovered bug lurking that will be a real pita to find. [04:43] lifeless, most Web apps with a "Log Out" button still have a "Shared computer" or similar checkbox on the login form [04:43] for cases when, for example, you pay for ten minutes of time at a cafe and don't *quite* log out in time [04:43] stub, excellent === stu1 [n=stub@gb.ja.99.196.revip.asianet.co.th] has joined #launchpad === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad [07:21] lifeless: ping? [07:24] pooong [07:27] lifeless: i am having a stupid issue with bzr [07:27] machine1 has the original archive. [07:27] people.ubuntu.com has a pushed one [07:27] machine2 branch from people [07:27] machine2 can't push to people.... [07:28] or i can't figure out how to let machine2 to do it [07:28] bzr branch sftp://people.ubuntu.com/home/fabbione/public_html/archives/system-integrity-check/ [07:28] works fine [07:28] whatever i try to say to bzr push towards that archive it ends up in an error [07:29] note that the archive is perfectly synced [07:29] no merges or new commits [07:29] bzr: WARNING: Unable to update the working tree of: sftp://people.ubuntu.com/home/fabbione/public_html/archives/system-integrity-check/ === lamont [n=lamont@mix.mmjgroup.com] has joined #launchpad [07:29] what am i missing here? [07:30] a) #bzr is the right place [07:30] b) its a UI glitch, its perfectly normal and correct [07:31] a) ok.. b) what should i do to workaround it? [07:31] theres nothing to workaround [07:31] check the exit code - its 0 [07:31] it is giving you a warning, not an error [07:31] ok [07:33] thanks mucho [07:33] np === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad === koke [n=koke@ubuntu/member/koke] has joined #launchpad === fabbione [i=fabbione@gordian.fabbione.net] has left #launchpad ["Ex-Chat"] [08:43] Merge to devel/launchpad/: [trivial] Drop is_person constraints (r3029: Stuart Bishop) [09:08] stub: ping [09:09] BjornT: pong [09:13] stub: nevermind, i was about to ask you about how to fix something, but i noticed it has already been fixed in rocketfuel === lbm [n=lbm@cpe.atm4-0-1301006.0x50a0824e.vgnxx6.customer.tele.dk] has joined #launchpad === carlos_ [n=carlos@112.Red-83-49-61.dynamicIP.rima-tde.net] has joined #launchpad [09:45] morning [09:51] good morning [09:55] lifeless: ping [09:55] Morning stevea === Kinnison thought you weren't allowed to look at your PC === cprov [n=cprov@217.205.109.249] has joined #launchpad [09:57] hi Kinnison. [09:57] That was yesterday. I'm much better today. [10:00] SteveA: phew [10:00] yeah ;-) [10:00] i think i'll take it easy on the eyes today, though [10:01] lots of workrave breaks === Kinnison nods === mdz [n=mdz@217.205.109.249] has joined #launchpad === SteveA [n=steve@195.182.78.95] has joined #launchpad === kiko [n=kiko@217.205.109.249] has joined #launchpad [10:24] hello there [10:24] how's it going [10:25] Kaboom! === kiko yawns [10:26] hey stub! [10:26] kiko: hey [10:27] how's it going? [10:27] The usual :-) [10:27] 'Nother lovely day in the land of smiles [10:27] naked girls, 30C, thai food, etc? === SteveA [n=steve@195.182.78.95] has joined #launchpad [10:28] hey SteveA [10:28] Naked girls are 15 minutes walk away, and only come out at night. But it is 30C and the food is good, cheap and plentiful :) [10:29] and what about the production update? === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [10:31] production update all done, patchlevels as discussed [10:31] thanks stub, rock and roll -- perhaps email launchpad and -users? [10:32] We need that log of changes for -users announcements, otherwise it would be a bit pointless (?) [10:33] I have a log of changes here, so sure. === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === jinty [n=jinty@135.Red-80-37-34.staticIP.rima-tde.net] has joined #launchpad [11:19] stub: ping? [11:19] SteveA: pong [11:19] i'm catching up with email [11:19] has the cached celeb stuff landed yet? [11:20] morning all [11:20] i was thinking about the cached celeb, and the mail thread about it [11:20] as sqlobject does cacheing like we want if we get an object by id, and as we want a launchpad instance to fail early if the celebs are not as expected [11:20] then we could re-do the celebs to do a single query / set of queries by name to look up celeb ids at startup [11:20] and then use celeb ids from then on [11:21] SteveA: Yes [11:21] and not need fancy cacheing proxies etc. [11:21] (landed) [11:21] __getattribute__ always makes me queasy [11:21] SteveA: __get__ makes me more queasy [11:21] I took jamesh's approach and simplified it, with comments about possible future enhancements. [11:22] Kinnison: __get__ ? as in from a descriptor [11:22] __get__ is just downright wierd, and I havn't found good docs on it yet [11:22] SteveA: aye, as in to do with how @property is done [11:23] SteveA, I looked at the current solution and it appears to be doing a lot of good in production [11:24] cool [11:24] i just read the mail from jamesh [11:24] i don't understand the part about thread-safety at the end though [11:25] SteveA, can you make it a priority this week to get jamesh' __len__ fix reviewed and landed? [11:25] ok [11:25] the final important fix we need to do is inTeam caching [11:25] I spoke to salgado about this [11:25] me too [11:26] and you, I remember now :) === kiko laughs [11:26] we don't want to do inTeam cacheing as such [11:26] right [11:26] you told me [11:26] so I was asking if you don't want to give salgado an idea of how you want this done, and have him implement it for you to review? [11:27] maybe. i'll look to see where we're up to with it [11:28] thanks -- I think salgado would appreciate being given that opportunity [11:39] stub: best doc on descriptors I've seen is http://users.rcn.com/python/download/Descriptor.htm [11:43] spiv: ta [11:49] stub, is launchpad going down for maintainence? === Kinnison wonders how upset this would get if I reached deep into this object and changed the receive buffer size [11:49] eight kilobytes is utter shite [11:50] Hmm, it's not the buffer, it's that for some bizarre reason it uses nonblocking receive === Kinnison goes to look deeper === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad === wiso_nid [n=meier@mail.weserve.ch] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [11:56] good morning! === wiso_nid [n=meier@mail.weserve.ch] has left #launchpad [] [11:58] kiko: nope [11:59] and the message is gone, too! === kiko scratches head [11:59] you saw a message? [11:59] yeah, on the webapp [11:59] bah - one of the appservers hadn't cleared its 'down for maintenance' file [12:00] Sorted [12:00] cool. [12:01] SteveA, talk to me, come on [12:03] 36ms SELECT private, owner, activitytimestamp, communityscore, datecreated, activityscore, title, duplicateof, description, hitstimestamp, hits, communitytimestamp, name, summary FROM Bug WHERE id = 633 [12:03] stub, is there any explanation on why that wouldn't take 1ms? contention? [12:04] contention [12:04] Or just busy === stub checks the load [12:05] 23ms SELECT id FROM BugExternalRef WHERE bug = 633 [12:05] Lots of disk activity [12:06] karma updater has kicked in [12:06] Which will continue to be slow until my patch is reviewed and landed [12:07] stub, what's blocking your review? [12:08] me not nagging anybody? [12:08] it's in the general queue [12:08] i'll take a look now [12:08] i need a change from EMAIL [12:08] SteveA, can you take that.. [12:08] cool [12:08] this will be a great week for perf [12:10] stub: what does WITHOUT OIDS mean? [12:11] By default tables get a magic column, but it is only really useful in rare cases (and even then, not strictly necessary). We don't need them anyway. [12:12] I'll be updating all the tables at some point to remove them, but it isn't urgent [12:12] WITHOUT OIDS is the default in 8.1 (or is it 8.0?) [12:24] SteveA: Apparently you were party to some local zope mods on jackass [12:24] SteveA: Did those ever make it into rocketfuel? [12:25] stub: reviewed [12:25] Kinnison: jackass? [12:26] what was running there? [12:26] SteveA: The poppy instance for dak [12:27] i don't recall zope mods for that, only poppy mods [12:27] is there a problem with running poppy? [12:28] cprov is encountering issues with some tests running on his laptop needing reconnects mid-upload [12:29] SteveA: yes, maybe you remember something about this issue [12:29] as far as i recall, all changes to poppy, and workarounds to connections being aborted on long uploads, were done in the poppy code [12:30] SteveA: gustavo added a weird polling on ftp.sock during the upload session, it needs further explanation. [12:30] what is the problem you're seeing? [12:32] SteveA: aparently the ftp connection drops during the upload session (it's not a long one) and the only way to recognize it is polling the ftp.sock (private attribute) and if it's gone ftp.connect() and ftp.login() again [12:33] hmm [12:33] so, there is a problem with the default ftp server code that the ftp connection will be aborted during an upload session, if the upload is long [12:33] beacuse the control connection will get no data for a while, even though the data connection is getting data [12:34] so the control connection will figure "oh, nothing happening, i'll disconnect" [12:34] i wrote a fix for poppy that deals with this [12:34] daf, Seems like tests are not detecting that I don't have installed python2.4-twisted-mail [12:34] daf, what's using it? [12:34] SteveA: and is it applied jackass instance ? [12:34] the fix didn't involve polling [12:34] carlos: I can't remember [12:35] it involved correctly resetting the activity timer on the control connection whenever some data arrives on the data connection [12:35] SteveA: the polling is in the client side ... [12:35] i have no idea what jackass is for, and where the fix was applied [12:35] carlos: buildd-sequencer.txt is what failed [12:35] ImportError: You need to have the Twisted Mail package installed to use twisted.protocols.smtp. See http://twistedmatrix.com/projects/mail. [12:36] the fix was certainly applied for poppy in production [12:36] because longer uploads would always fail without it [12:36] hmm, I see [12:36] daf: dapper ? [12:36] cprov, yes [12:36] cprov: yes [12:36] daf, import_fascist is missing that import then [12:36] cprov: twisted pkg was split in a wierd way, maybe lp-deps isn't up [12:36] daf, it detected the web package [12:37] but didn't complain about the mail one === daf shrugs [12:37] this was when running python test.py -f yesterday === mdz [n=mdz@217.205.109.249] has left #launchpad ["Ex-Chat"] [12:37] cprov: see poppy/server.py, class STORChannel [12:37] SteveA: I suspect we are talking about the same patch ... elmo just gave it to me ... will isolate the patch an send you, ok ? === mdz [n=mdz@217.205.109.249] has joined #launchpad [12:38] carlos: and yes, the fascist does appear in the traceback [12:38] cprov: ok. what code are you using? how does it compare to the code in RF? === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [12:41] daf, hmmm I don't see it, perhaps other failures are hidding it.. [12:42] SteveA: so, I have RF HEAD and a kind of special zope+poppy instance from elmo [12:42] SteveA: I can see the class STORChannel(OriginalSTORChannel): [12:43] SteveA: I can't see where is the respective code in RF === niemeyer [n=niemeyer@200.138.34.5] has joined #launchpad === beyond [n=beyond@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:48] niemeyer: hey, how is it going ? [12:48] Buenos dias! [12:48] fala niemeyer [12:49] cprov: So far so good :) [12:49] niemeyer: maybe you have some info to bug # 29645 [12:49] niemeyer: this is a sabdfl's phrase, you need to find other ;) [12:50] cprov: Ah, didn't know that.. will look for another one :) [12:50] cprov: Will check it [12:50] niemeyer: good, thx === niemeyer is not allowed to see the bug.. === niemeyer is surprised for getting a backtrace saying that.. :) [12:56] cprov: ^ [12:59] niemeyer: try again [12:59] cprov: Is the backtrace expected? [12:59] Umm, given a list L, what's the best way to produce list K which is [ L[0] , L[0:1] , L[0:2] , ..., L ] ? [01:00] [L[:i] for i in range(len(L))] ? [01:00] Perhaps (1, len(L)) [01:00] niemeyer: it's not, thought it's been solved, file a bug [01:01] niemeyer: (1, len(L)+1) does the trick, ta === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:01] Kinnison: The +1 after len(L) shouldn't be needed.. [01:02] It is [01:02] otherwise it stops one earlyu [01:02] s/u$// [01:02] Kinnison: [01:02] >>> L = [1,2,3] ; print L[:len(L)] [01:02] [1, 2, 3] === doko [n=doko@dslb-084-059-096-046.pools.arcor-ip.net] has joined #launchpad [01:03] range(a,b) is from a to b-1 [01:03] range(10) is 0-9 [01:03] Kinnison: Duh, right === Kinnison tickles niemeyer [01:03] [L[:i+1] for i in range(len(L))] would do the trick then === Kinnison tries to decide which is nicer [01:04] the latter I think [01:07] kiko, mdz: on libcommand* in universe sources now [01:18] Merge to devel/launchpad/: [r=SteveA] Karma cache refactoring (r3030: Stuart Bishop) [01:18] rock and roll stub [01:20] kiko, mdz: libxml* [01:20] I love the initial publish process [01:20] it makes me so happy [01:21] it is so friggin slow [01:24] kiko: it's relative, do you have a faster replacement ? so, current publisher is the fastest ! we can have so much fun watching spn crossing the screen like in a 9600 bps terminal ;) [01:25] like a fast link to QSD in the old days [01:26] malone: why are assigned "needs-info" bug not listed in "My Assigned Bugs" ? [01:27] because they are needs-info. [01:27] kiko: it's unfair IMO, I would like to keep track of my needs-info bugs too [01:28] it's been the subject of some debate [01:28] you can query them using the advanced form if you like [01:28] kiko: uhm ... could be a solution [01:28] kiko: If you can work out a faster way to drag a file down from an HTTP server other than using urllib2.urlopen() then you win a prize === cprov feels the bugzilla deja vu when using Malone Advanced Search === Kinnison grins [01:35] daf, ping? === JanC [n=janc@lugwv/member/JanC] has joined #launchpad === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [01:39] kiko: pong === GoRoDeK [n=gorodek@p5083FA19.dip.t-dialin.net] has joined #launchpad === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad [01:51] daf, you don't talk to me padrino [01:52] oh, bah [01:52] I need to register [01:53] carlos: ping [01:54] SteveA, pong === AlinuxOS [n=Ubuntu@d83-176-95-187.cust.tele2.it] has joined #launchpad [02:08] stub: maybe it's me, but when I read your "What is a Product Series" mail, all I see is a barrage of "you're on crack ddaa". [02:08] makes it difficult for me to reply [02:10] I'll try... [02:11] bah [02:11] selecting ValidAssignee timed out for me, any idea? [02:11] (I was trying to assigna bug to Scott) [02:12] spiv, hi, around? === jsgotangco [n=jsg@210.4.12.147] has joined #launchpad === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad [02:21] carlos: Yeah. [02:21] spiv, hi, I'm having problems with your suggested 'self.form.extractOneKey' method [02:21] and I was not able to find any reference to it... [02:22] isn't it just self.form[key] ? [02:23] spiv, I'm talking about review of PoMsgSetPage [02:23] s/about/about your/ [02:24] I think fel.form[key] can contain a list [02:25] carlos: let me look at my review, I think I was proposing that there should be one, rather than there is one.. [02:26] hmm [02:26] carlos: right, it was a hypothetical method name. [02:26] ok, I misunderstood you :-P [02:26] daf, really? [02:26] sure [02:26] daf, I suppose it depends on the form, right? [02:26] carlos: The thing is, you're doing a fair bit of manual mucking about because you want forms to have more data than simple key/value pairs. [02:26] http://launchpad.net/blah?foo=a&foo=b [02:26] if you add twice the same entry [02:26] form['foo'] = ['a', 'b'] [02:27] I think [02:27] daf, right [02:27] Although as daf points out, you can actually include the same key multiple times in the same form. [02:27] spiv, well, our forms should have just one key [02:27] if we have more than one is either bad user input [02:27] or a bug [02:28] carlos: interesting, that wasn't at all clear to me from reading the code. [02:28] so I think is safe to assume it's just one element and show an error if we get a list [02:28] Oh, sorry, I see what you mean. [02:28] I think ;) [02:28] spiv, let me show you the new code [02:28] I changed it [02:28] Sounds good :) [02:29] ddaa: how can I register my a branch of mine with LP ? [02:29] ddaa: I have it published and accessible http, can I do that without an admin intervention? [02:29] spiv, https://chinstrap.ubuntu.com/~dsilvers/paste/fileICjL4I.html [02:30] spiv, I need to change the extractOneKey call with self.form[] [02:30] sivang: if it's a bzr branch, it's just "add branch" on the corresponding product, or on your person's page if it has no associated product. [02:31] and I suppose that I should also check if 'key' is a list to show an error === cprov [n=cprov@217.205.109.249] has joined #launchpad [02:32] carlos: So, I guess I didn't explain my idea so well. [02:33] ddaa: ok, is it ok to open a project for it, if it's a project based on a specification? [02:33] spiv, I discarded the record idea [02:33] carlos: It looks to me as if it would be simpler if you could pass structs in forms. [02:33] spiv, I have the explanation in my email [02:34] carlos: because really set_1_msgid and set_1_translation_... look like they're effectively different attributes of the same thing. [02:34] Hmm, ok. [02:34] You mean the specific implementation, or the whole concept? [02:34] sivang: you mean "a product". You can create a product if you want, you do not need to, and I believe you are able to change the product after registration, so you can postpone the product creation. [02:34] spiv, but as a summary, I don't think we need to add support for records just for this part of launchpad, we don't have a hard restriction on them [02:34] sivang: just do what makes most sense to you, if that's not supported by Launchpad, that's a bug. [02:35] carlos: Well, you're basically doing the same thing ad hoc. [02:35] spiv, you are right, it's a record, the concept is what you said, but the implementation... I'm not sure we should do it now unless other parts of launchpad can reuse it too [02:35] spiv: yeah, it's almost like a dum/restore [02:35] carlos: So I'd be tempted to just use the stuff that's already built into zope 3 to ease this stuff. [02:35] dump [02:36] (written late one night in Mark's flat, IIRC) [02:36] hmm I thought we need to do some changes to launchpad to be able to use it === doko_ [n=doko@dslb-084-059-108-228.pools.arcor-ip.net] has joined #launchpad [02:36] spiv, if it's already there... I will try that path then [02:37] carlos: It seems to be in there already, I think, but maybe it needs a small tweak to activate it. [02:37] ok, I need to talk later with SteveA I will check it with him [02:37] to be sure [02:37] spiv, thanks [02:37] carlos: I would like to get a zope expert's opinion on the topic, too, because I'm not sure if that particular feature is considered a good idea in zope 3 or not. [02:37] Yeah, check with Steve. [02:37] what code is this, by the way? [02:38] As far as the review goes: [02:38] s/code/branch/ [02:38] daf, PoMsgSetPage [02:38] aha [02:38] daf, chinstrap.ubuntu.com:/home/warthogs/archives/carlos/launchpad/PoMsgSetPage/ [02:39] I'm happy enough for that code to be merged with your ad hoc pulling processing of this structured form -- but I strongly suspect this won't be the only bit of launchpad where this may be useful, hence my interest in a more general solution. [02:39] let's file a bug on it === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad [02:39] daf, let's ask Steve first ;-) [02:39] I think it would simplify the code in a good way [02:40] even if it's only useful here [02:40] sure, pending Steve's approval [02:40] ok [02:40] carlos: Thanks for describing your use case for me so I fully understand what you need [02:40] spiv, no, thanks for your input ;-) [02:41] daf: I agree it would be nicer, but if it's just for this one piece of code, it may not be worth it. [02:41] Anyway, we have a plan of action now :) [02:41] yes === cpro1 [n=cprov@217.205.109.249] has joined #launchpad === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #launchpad === cpro1 [n=cprov@217.205.109.249] has joined #launchpad [02:52] spiv: there is various form marshalling stuff in zope3, as in zope2. but i think it is not the right way to do it -- it leads to more problems than it solves === cpro1 [n=cprov@217.205.109.249] has joined #launchpad [02:53] and it is largely unused for that reason, and also because we have forms and widgets now for the same kind of thing [02:53] daf: so, how can I remove the project I've open and open a product instead of it, and associate the bzr branch to it? [02:53] sadly, you can't delete projects [02:53] spiv: we could think about adapting a request to an IFormData kind of thing, and have useful APIs on an IFormData, perhaps [02:53] daf: AFAICT I only need one product with one associated branch [02:53] I would just create a product with the same name [02:54] spiv: including getOneKey or some such [02:54] then there should be an "Add Branch" link [02:54] daf: ok, will do, thanks [02:54] so, we can have a launchpad-specific API on forms without extending the Zope3 request a lot === cpro1 [n=cprov@217.205.109.249] has left #launchpad [] [02:54]