=== scorpix [n=ali@as8-123.qualitynet.net] has joined #launchpad [12:06] when i try to create an Arabic template for Gaim i get this error: Sorry, you don't have permission to access this page. [12:08] how can i create a Translation Template for gaim? === camilotelles [n=Camilo@20132194128.user.veloxzone.com.br] has left #launchpad ["Leaving"] === beyond [n=beyond@201-27-7-58.dsl.telesp.net.br] has joined #launchpad === Ubugtu` [n=bugbot@81.171.100.21] has joined #launchpad === netjoined: irc.freenode.net -> brown.freenode.net === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #launchpad === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad === netjoined: irc.freenode.net -> brown.freenode.net === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #launchpad === lamont [n=lamont@mib.fc.hp.com] has joined #launchpad === interalia [n=interali@adsl-60-232.swiftdsl.com.au] has joined #launchpad === Nafallo is now known as Nafallo_away === jinty [n=jinty@205.134.224.215] has left #launchpad ["Leaving"] === dewd [n=dewd@201009186135.user.veloxzone.com.br] has joined #launchpad === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #launchpad === Burgundavia [n=corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad [04:17] lifeless: canonical.librarian.storage._relFileLocation === Alinux [n=Ubuntu@d83-176-70-43.cust.tele2.it] has joined #launchpad === poningru [n=poningru@pool-70-110-75-241.tampfl.fios.verizon.net] has joined #launchpad === stub [i=stub@sweep.bur.st] has joined #launchpad [06:09] lifeless: I have so far been unable to tag sftp://chinstrap.ubuntu.com/home/warthogs/archives/stub/launchpad/production/1.40 as sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/production/1.40 - I keep getting back the same error "PQM Cannot merge between different VCSsystems." === lamont [n=lamont@mib.fc.hp.com] has joined #launchpad === Keybuk [n=scott@descent.netsplit.com] has joined #launchpad === lbm [n=lbm@cpe.atm4-0-1301006.0x50a0824e.vgnxx6.customer.tele.dk] has joined #launchpad [08:17] SteveA, jamesh, spiv: open-id looks like what we want for allowing people to authenticate against Launchpad. It seems complicated enough to support our requirements, and not much more so. I think we should run with this rather than reinvent it badly. It would be good if you can have a look over the specs to double check my opinion when you have time [08:18] (this isn't scheduled or assigned yet, so not urgent - just something there are persitant mutterings about) [08:29] stub: okay. i'd stay stick the URLs and rationale in a bug or spec, and we'll look at it February earliest [08:30] no point looking earlier as we have a whole bunch of polish and stability work on launchpad before then [08:30] if you get me a good URL, i'll take a brief look now === robitaille [n=robitail@ubuntu/member/robitaille] has joined #launchpad [08:38] SteveA: spec is at http://openid.net/specs.bml, and we have a bug open about it here: https://launchpad.net/products/launchpad/+bug/1169 [08:38] Malone bug #1169: Launchpad should support OpenID Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/1169 [08:39] the spec feels like it would be easier to understand with some more examples and maybe sample code [08:45] i've read the overview. so, the idea is that we provide on the launchpad end the facility for anyone to say "I am NAME from Launchpad", and a registry of to which sites Launchpad will say "NAME says you can use Launchpad to authenticate with you" [08:48] yeah [08:48] People say 'I am https://launchpad.net/peope/stub', and other systems can redirect to launchpad, get us to do authentication, and send back a cookie [08:48] it works by the remote site bouncing the user through the OpenID server's website and back again [08:49] erm... I should say token. Cookie has too many meanings [08:49] so the OpenID server can check the user's credentials (cookies, basic auth, SSL client certs, or whatever else) [09:10] stub: any items for the meeting agenda today? [09:10] Ooh... its thursday. [09:10] Erm... just production and staging as normal, following up on my status report to launchpad@ [09:11] i need to look through my summary of the last meeting. there were some things mentioned there [09:11] what about a gina run? [09:11] that still hasn't happened [09:11] Nope. People want more runs on staging. [09:12] (which has been rebuilding the db for the last 3 hours now - daily syncs no longer look possible.) [09:16] too much data? === zyga [n=zyga@2-mi2-1.acn.waw.pl] has joined #launchpad [09:17] SteveA: Yes - db is growing. Should be fine - I'll just need to schedule a database sync once or twice a week instead of every day. We can keep going with the daily code drops. [09:19] does syncing take a lot longer than copying the raw data? === carlos [n=carlos@81.Red-83-49-60.dynamicIP.rima-tde.net] has joined #launchpad [09:22] morning [09:24] SteveA: Yes - raw data is about 4.5GB. Importing that data into PostgreSQL takes time, and then constraints need to be created and checked, and indexes on that data need to be built. [09:24] morning carlos [09:24] SteveA: We could throw RAM at the problem, but it would only delay the inevitable [09:24] carlos: Hi [09:25] so, you can't just copy the raw database files? [09:26] carlos: morning [09:26] carlos: just pull and have a look [09:26] carlos: it was easier than I really thought [09:26] zyga, you have it already? [09:26] dude you rock... === carlos checks [09:26] no it was just plain easy this time :) === sivang notes so many things are easier in python. GnomeVFS from within it is plain candy [09:29] zyga, I see, you just import all .po and .pot files available, right? [09:29] right [09:29] I think we need a mapping between 'gnome' products and 'our' products [09:29] I don't thing they are 100% identical [09:30] zyga, yeah, I will create a log when I don't create a product in our database [09:30] so we can create or detect that problem [09:30] s/create/create a new product/ [09:30] so do I need to add anything now? [09:31] zyga, hmmm, anyway... In the long term, if you were able to use the .xml to filter out obsolete .po and .pot files... sometimes we have such files there [09:31] SteveA: No - that would involve shutting down emperor to keep the datafiles clean. And even if we could do it with no downtime (eg. a snapshot capable filesystem on emperor), it isn't exactly supported and would introduce more variables into the staging environment (which would be bad). [09:31] zyga/carlos: make sure the contributed code has a comment at the top with copyright who wrote it, when, and what the licence is [09:31] zyga, but I think that's enough to start the import [09:31] SteveA: it's there :) [09:31] #!/usr/bin/env python [09:31] # (c) Zygmunt Krynicki 2005, [09:31] # Licensed under LGPL, see COPYING for the whole text [09:31] stub: i see. so postgresql doesn't have that facility at this point [09:31] carlos: okay, the XML will be the second shot but we still need language information, xml don't has it [09:32] zyga, don't worry about the language information [09:32] zyga, what I mean is use what you have [09:32] and the xml to generate a list of products + branches [09:32] SteveA: I don't think any DB's do. [09:32] zyga, if a .po or .pot file come from a branch or product that the xml does not have, just ignore it [09:32] Well.. maybe some of the toys. [09:33] stub: FileStorage and DirectoryStorage do ;-) [09:33] zyga, we will care about the languages on import time [09:35] zyga, hmm, also, would be really useful if you would give me another argument that we have available from the .xml file, the path from where the file comes, but that's a plus [09:35] hmm [09:35] zyga, I forgot to comment it to you yesterday [09:35] okay so let's get this straight [09:36] we don't care about languages at all right now, just about products+branches [09:36] and for each p+b you want a path, right? [09:38] carlos: strainght from the XML: module/version/component@dir [09:39] zyga, right [09:39] zyga, if you give me the path + filename, that's enough for me [09:40] as a single argument [09:40] filename? [09:40] to the pot? [09:40] the filename of the content you give me, like evolution-2.2.pot [09:40] or evolution-2.2.es.pot [09:40] sorry, .po [09:40] module/version/component@dir + module/component/potname@name [09:41] hmmm [09:41] hmm, right now we can just add getURL() to FileToSync [09:41] yeah, for the .pot file that's perfect [09:41] k [09:41] I don't need the URL, just a path to the .pot file [09:42] the path on the server, right? [09:42] and for the .po files the path+ the filename as you have it at l10n-status.gnome.org [09:42] ok [09:42] zyga, the path on the source tree [09:45] carlos: okay just to be sure, the xml has that data in: potfile-in-source-tree: module/version/component/podir@dir + module/version/component/potname@name [09:46] branches+products need to come from the xml while the actuall list of .po's come from index.txt [09:47] zyga, private message so I don't send spam here... === poningru [n=poningru@pool-70-110-75-241.tampfl.fios.verizon.net] has joined #launchpad === scorpix_ [n=ali@ask16-96.qualitynet.net] has joined #launchpad [10:23] spiv: > + tm = initZopeless(config.builddmaster.dbuser='fiera') [10:23] does that make sense at all? [10:23] or is it someone's search-and-replace taken too far? [10:26] SteveA: it's a syntax error, so it is probably the latter [10:34] jamesh: so it is. thanks. === Nafallo_away is now known as Nafallo [10:36] jamesh: error reporting looking okay? [10:37] SteveA: yeah. I need to write some more tests for it and clean things up [10:38] SteveA: I've got it writing the reports to files, and showing the error identifier on the error web page === carlos workraves [10:41] that's great [10:42] i'm looking forward to getting this into production and on staging, as it will make the QA work a lot easier and more effective [10:43] it will also let users of launchpad know we can find out what went wrong in their particular case in a more straightforward way [10:43] also, i'll be able to turn off the in process /error pages [10:44] Do we still want the exceptions sent to the logging framework? [10:44] (I think the current system does so) [10:46] yes, at least when running on development boxes [10:46] no point really when running in production [10:46] config file setting, perhaps? [10:46] sounds good === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [11:31] carlos: there? :-) [11:31] Nafallo, hi [11:32] carlos: morning. I think we should kill of sv_SE completly. ppl only translates more and more in it as long as it exists. [11:33] doable? :-) [11:33] Nafallo, yes, but you need to merge first those translations into 'sv' [11:34] Nafallo, get a .po file, merge it by hand with the one from 'sv' [11:34] and upload the merged one into 'sv' [11:34] then, ping me with the URL of the merged pofiles [11:34] and we will get ride of them [11:35] hmm, oki. I'll start with that as soon as time provides then :-) [11:35] jamesh: ping === Nafallo just got more memory for his server :-) [11:36] Nafallo, ;-) [11:39] BjornT: hi [11:40] jamesh: hi. i'm trying to fix bug 3207, but i fail to create a test case for it [11:40] Malone bug #3207: line endings must be canonicalised before checking signatures on PGP/MIME messages Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Bjrn Tillenius, Status: Accepted http://launchpad.net/malone/bugs/3207 [11:41] jamesh: do you have any idea how to create an email, signed by sample person, that behaves like the email in that bug? [11:43] BjornT: Shouldn't be too difficult to do with the email library (/me crosses fingers) [11:44] create the message part and serialise it with '\r\n' line endings, sign it, and wrap the content and signature in a multipart message, then convert all the line endings back to '\n' (or '\r') [11:47] jamesh: yeah, i've tried doing like that manually. i'll try again using the email library, though, maybe i missed something [11:52] ok, so it looks very likely that we'll have mailman as an official rosetta product :) === carlos workraves === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad === matsubara [n=matsubar@201-27-7-58.dsl.telesp.net.br] has joined #launchpad [12:05] good morning === cprov [n=cprov@201-27-7-58.dsl.telesp.net.br] has joined #launchpad [12:08] morning hackers [12:09] jordi, dude, you rock! [12:09] :-) === beyond [n=beyond@201-27-7-58.dsl.telesp.net.br] has joined #launchpad === salgado [n=salgado@201-27-7-58.dsl.telesp.net.br] has joined #launchpad === Nafallo is now known as Nafallo_away === mbp_ [n=mbp@ozlabs.org] has joined #launchpad === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [12:34] developers meeting in 25 mins === SteveA [n=steve@195.182.78.95] has left #launchpad ["Leaving"] === SteveA [n=steve@195.182.78.95] has joined #launchpad [12:35] any other items for the agenda === kiko [n=kiko@201-27-7-58.dsl.telesp.net.br] has joined #launchpad [12:38] hey there [12:39] hi [12:39] martin! [12:39] how's it going man? [12:39] man [12:40] too slow; too much to do :/ === SteveA back in 10-15 mins [12:41] heya SteveA [12:41] mpool, how can I help you? [12:42] oh i don't know [12:42] come on [12:44] kiko: barry, you asked last night, is the main author of mailman [12:45] and he's probably jumping onto the Launchpad! [12:45] wow well done [12:45] mpool: Martin! it's been sometime since i last saw you online [12:46] jordi, barry warsaw? I know him [12:46] in person? [12:46] that's awesome [12:46] jordi, so he wants to translate mailman inside rosetta? [12:46] more power to him [12:46] yup [12:47] kiko: yeah, more and more upstream projects to officialize in Rosetta [12:47] cool [12:47] argh [12:47] I posted to allhands [12:50] now, it's going to be a week of rejections :) [12:50] according to the new policy [12:52] jordi, ;-) [12:52] kiko: http://lists.ubuntu.com/archives/rosetta-users/2005-November/001054.html [12:52] the outstanding issue is how to convert the mail templates to po and viceversa [12:53] sivang: oh, hi [12:53] i have a good photo of you on flickr [12:54] mpool: yeah, I saw it :) good, but chunky :) [12:54] mpool: can I PM you? [12:54] sure [12:57] well, presumably you can [12:57] is it not workiing? === SteveA [n=steve@85.206.173.85] has joined #launchpad === bradb [n=bradb@London-HSE-ppp3552267.sympatico.ca] has joined #launchpad [12:58] mpool: let me try again [12:58] morning bradb [12:58] meeting in 2 [12:58] that's true [12:58] mpool: after meeting then [12:58] not a bad time for a brief wrist / eyes break [12:58] hey kiko === koke [n=koke@ubuntu/member/koke] has joined #launchpad [12:59] Welcome to the launchpad developers meeting [01:00] jordi, great set of answers to barry [01:00] congrats [01:00] who's here today? [01:00] Bonjour. [01:00] "the world is bright" [01:00] me [01:00] sveiki [01:00] me === cprov me [01:00] me [01:00] me [01:00] chu l [01:01] me [01:01] me [01:01] yo [01:01] apologies from: jblack, lifeless, neimeyer, daf, mpt [01:01] bradb: looks like the encoding bug is gone. [01:01] ddaa: on OS X right now [01:01] me [01:02] == Agenda == [01:02] * Roll call [01:02] * Agenda [01:02] * Next meeting [01:02] * Activity reports [01:02] * Items from last meeting [01:02] * Production / staging (stub) [01:02] * Production gina run (stub) [01:02] * Naming of functions, methods, attributes and properties. (SteveAlexander) [01:02] * Launchpad user community meetings. (SteveAlexander) [01:02] * A launchpad mailing list for everyone. (SteveAlexander) [01:02] * Keep, Bag, Change (Kinnison) [01:02] * Three sentences [01:02] [01:02] is Kinnison here? [01:02] /msg me any things you want added, although there is quite a bit here [01:03] okay. next meeting... [01:03] I vote for same time same place [01:03] lifeless asked for it to be earlier. but, today isn't the best time to discuss it === cprov nods [01:03] as lifeless and jblack and mpt are not here [01:03] so, same time next week. [01:03] one hour earlier will be cruel with bradb I suspect [01:04] Les absents ont toujours tort ;) [01:04] activity reports: [01:04] i totally suck. none since last week. [01:04] who can claim better than me? [01:04] yeah, 6AM is somewhat harsh for a meeting :) === jamesh sucks === carlos sucks too [01:04] I started them today === BjornT is up to date === cprov is up === ddaa zuptoodait === bradb is up to date [01:05] i'd like earlier === salgado lost two days but went back on track since yesterday [01:05] I'm up to date since last meeting (although I didn't keep great notes for all days, I sent what I have) [01:05] haven't sent yesterday yet === gneuman [n=gneuman@201-27-7-58.dsl.telesp.net.br] has joined #launchpad === stub is up to date [01:06] gneuman and matsubara are up-to-date (though he sends his to me directly) [01:06] okay. send *something* every day. [01:06] maybe set an alarm for a particular time, like 5pm local [01:06] and send them each day at that time, when the alarm goes off [01:07] well done to those who are up to date and have sent several since last week [01:07] i salute you [01:07] - items from last meeting [01:07] we've covered the agenda items [01:07] X-Launchpad-Bug was resolved [01:07] thanks brad [01:08] THANKS bradb [01:08] np [01:08] various stuff has happened in the gina department [01:08] we have a new translation policy [01:08] in the soyuz department better said [01:08] right [01:08] so, that's it from last time [01:08] (so major credits to Kinnison and cprov) [01:08] * Production / staging (stub) [01:09] I failed to do a production rollout this week due to some bzr issues (reported to Robert). [01:09] Depending on when things get sorted, I'll either be do a rollout tomorrow and skip next week, or doing the rollout Monday or Tuesday. [01:09] I will roll out a two day old HEAD (so what landed yesterday if I get to rollout tomorrow) [01:09] Staging had similar issues. The staging database is currently being rebuilt (it is currently in the final stages). I suspect the code update will fail. [01:09] Due to size increases with the production database, syncing the staging database to production is now taking several hours so I'll need to cut back database syncs to once per week. Code updates can continue as usual (daily) once we have finished Gina and Publisher testing. [01:09] ffs, sorry. I'm here. [01:09] hi jordi === Kinnison is here [01:10] sorry, forgot to start irssi === camilotelles [n=Camilo@20132194128.user.veloxzone.com.br] has joined #launchpad [01:10] stub, so can we assume that staging will be updated once per week starting next week? [01:10] kiko: thanks :) === carlos talks about the database [01:10] carlos: The staging *database* will be synced once per week. I think sunday is the best choice. [01:10] stub, will not be stopped by gina or bugzilla migration scripts? [01:11] carlos: Yes - depending on the status of Gina and Publisher testing. [01:11] carlos, the gina/bugzilla situation is an interim measure. it's not ideal, but it won't last forever === carlos is still using staging db to generate language packs [01:11] as soon as they are run staging can go on doing daily updates [01:11] carlos, can you explain why? [01:12] I think I only need one more bugzilla import test on staging, so that should get cleared up after the next gina run [01:12] kiko, because the procedure is not yet working as it should so it gives me more control over the process until I can say it's production ready [01:13] okay [01:13] carlos: We can arrange a seperate mirror of the production database if staging becomes unsuitable. Let me know. Might need hardware, but I think something can be found short term. [01:14] stub: I assume "depending on the status of..." means that for now, we'll do one db sync and then wait [01:14] Kinnison: Yes [01:14] stub, are you saying that we should stop syncing daily as our policy? [01:14] stub: cool [01:14] stub: cool [01:14] I was considering the current situation as temporary [01:14] stub, ok, If i see it'sneeded I will tell you it [01:14] kiko: We can still sync daily - it just means that staging will be unavailable for maybe 9 hours each day. Which is silly. [01:15] we'll be having increasing problems until we get R/O replicas going i think [01:15] kiko: Before, it was only taking 1.5 hours which was fine. [01:15] stub, is this database or librarian growth? [01:15] kiko: Database. [01:15] stub: is this related mostly to fti? [01:16] kiko: staging doesn't seem to copy the production librarian files [01:16] Kinnison: No [01:16] hmmm. [01:16] stub, if I asked you what's grown so much would you say Rosetta or something else or don't know? [01:16] an rsync should do for the librarian. or even something cleverer based on those files that have been added since last time [01:16] There is a special hack in the librarian, where it will grab a file from an upstream librarian if the file isn't available locally. Which means we don't have to sync the librarian to staging. (if it is working) [01:17] oh, i remember Kinnison and cprov doing that, i think [01:17] it's not working, we think [01:17] kiko: Staging is a big one. [01:17] kiko: Erm.... c/Staging/ShipIt [01:17] i think we're okay for this week [01:17] let's move on [01:18] * Production gina run (stub) [01:18] or not stub... [01:18] Various people are feeling paranoid, so Gina is not being run on production until she has had more time on staging. If things go smoothly, I suspect we can finally do the production Gina run week after next (which we can confirm next meeting). [01:18] can someone give a brief summary of where we stand with doing a gina run on production === scorpix_ [n=ali@ask16-96.qualitynet.net] has left #launchpad [] [01:18] do we need to get elmo to the next meeting? [01:19] SteveA: mdz would be of more use [01:19] hmmm [01:19] mdz will be well asleep [01:19] SteveA: but it's a nasty time for him I think [01:19] so the current situation with gina [01:19] we are running comparisons once we have imported and published an archive [01:19] anyway he can tell folks. so long as we have a good summary at the next meeting, that's fine [01:19] we believe there are no showstopper gina issues [01:19] there should be no major publisher issues [01:19] but it's a matter now of getting the diffs between archives to a manageable size [01:20] this is made a bit more difficult by the fact that the existing archive had issues [01:20] so we are actually fixing some things in the migration [01:20] I'm responsible for this so I'm probably okay with giving the report on whether it's okay or not (and coordinating with people to find out) [01:20] ok [01:20] thanks [01:20] * Naming of functions, methods, attributes and properties. (SteveAlexander) [01:21] there was proposal on the list by niemeyer. brad supported niemeyer's proposal. [01:21] i also support niemeyer's proposal. [01:21] so, now is your last chance to say you totally can't live with... [01:21] all attributes, properties, methods and functions in launchpad code being of the form foo_bar_baz and not fooBarBaz [01:22] I am in favor of this. [01:22] except where this is not possible because you're subclassing something that uses a different style, for example === jinty [n=jinty@205.134.224.215] has joined #launchpad === Kinnison dislikes it, but I can appreciate the desire for consistency === BjornT prefers fooBarBaz for methods, but doesn't care that much [01:22] Can live with whatever. But I came to prefere the methodName style. === Kinnison nods BjornT [01:22] I am more interested in how we plan to handle a "migration" [01:22] my personal preference is fooBarBaz for methods, and foo_bar for functions, attributes and properties === carlos thinks like BjornT, but will accept this new policy [01:23] Also, code that interface with e.g. Twisted will end up as an odd mix of both styles. [01:23] but it is a more complex rule [01:23] ddaa: code that interfaces with other systems should use one style consistently === Kinnison thinks fooBarBaz for methods, and foo_bar_baz for globals [01:23] so, if we can't use just the launchpad style, then that module / class should use another style [01:23] I'm okay with what niemeyer suggested [01:23] except unittest tests, which will generally be test_the_foo_bar_works [01:24] also, PEP-8 seems to be slightly in favour of foo_bar [01:24] Well, I like test_ItWorksYeah [01:24] hu test_itWorksYeah [01:24] but in a database class, the attributes that are in fact database columns will be inconsistent with other attributes [01:25] they already are. [01:25] okay. i didn't hear any serious dissent. [01:25] Look like quite a few people like the other style, but nobody is willing to argue about it. [01:25] i'd like to hear one of the following from everyone: -1 -0 +0 +1. where -1 means NO WAY, and +1 means PLEASE YES! [01:25] salgado: We have decided that database columns should be this_is_a_value too, rather than thisisavalue [01:25] please say now [01:25] salgado: But there will be no mass migration [01:26] and say quiet otherwise until we're done === cprov is happy to have any *single* pattern [01:26] -1 (-0 if someone explains the policy for existing code refactoring and it's not insane) === SteveA +1 === kiko +1 [01:26] -0 [01:26] +1 [01:26] -1 (caps style is faster to type and strains less on the wrists) [01:26] +1 [01:27] +0 [01:27] _0 [01:27] +1 [01:27] +0 ... [01:27] -0 [01:27] 0 (I can't use a consistant style myself, so am not going to be a hypocrite and pretend I should be listened to on this) [01:27] (i don't really get a vote, but i_like_this()) [01:27] any more for any more... [01:27] to Kinnison: [01:27] I also don't get to vote, but I tend to follow ddaa on that [01:27] the policy will be that all new totally new code will be in the new style. [01:28] where new code touches an existing class or unit of code [01:28] it should either [01:28] - use the existing style (for a small change) [01:28] - rework the unit of code to use the new style (for a large change) [01:28] Can you define small vs. large changes? [01:28] In particular, you could have a massive rework of implementation that doesn't touch interface [01:28] no. it's between you and your code reviewer. [01:28] is that a small or large change? [01:29] depends on the nature of the interface [01:29] Well, simply based on my dislike of the style chosen, I'm going no higher than -0.5 [01:29] use common sense, and ask the review team for advice === Kinnison will live with it, but will sulk quietly when alone [01:30] we have -1 from ddaa, -1 from sivang (you get to vote, but it might not be totally counted), and -0.5 from Kinnison [01:31] everyone else is in favor or can live with it [01:31] ddaa: can you live with it? [01:31] Sure, I can live with anything short of rot13. [01:31] okay. then it is decided. [01:31] thanks everyone for keeping this brief. [01:31] SteveA, does it affects current code being reviewed? [01:31] no [01:32] like my TranslationUploads branch [01:32] unless you want it to, as a code author [01:32] ok [01:32] the point is, this should not result in lots of extra work for anyone [01:32] use that as a guideline [01:32] * Launchpad user community meetings. (SteveAlexander) [01:32] i think we should have meetings that aren't in the strict structure of these developer meetings [01:33] and invite our user community to participate more [01:33] including the distro team [01:34] i'd like some feedback from you as to whether this is a good idea, and i'd like someone other than me to set the first one up [01:34] the timezone should allow mdz to attend [01:34] I think it's a good idea. [01:34] and ideally mpt === Kinnison thinks that's a good plan [01:34] very good idea. I would also have meetings dedicated for walkthrough and guidance for using launcpad for upstream maintainers, [01:34] I can set this up if nobody else isn't interested. mdz and mpt together will be difficult when mpt is back in NZ, though. [01:35] kiko: thanks. [01:35] we could also invite them and show them the nice features they can use first hand [01:35] * A launchpad mailing list for everyone. (SteveAlexander) [01:35] right now, we use the launchpad list just for development discussions. [01:35] it doesn't get a lot of traffic usually [01:35] i think we should open up this list [01:36]