=== dand [n=dand@83.103.205.67] has joined #launchpad === stub [n=stub@203-214-4-72.dyn.iinet.net.au] has joined #launchpad [12:25] heya stub [12:26] yo [12:29] yoiifcation [12:31] how goes it [12:31] hey sabdfl [12:32] kiko: excellent thanks. you? [12:32] pretty good. glad to see you back in the london seat! had a good rest? [12:33] hi [12:34] Is Steve's navigation work ready for production rollout Tuesday? [12:34] stub, I need to merge them in to test, first [12:34] it's a pretty big change [12:35] kiko: There was a patch from salgado improving the shipit export file name. Do you happen to know if it unguessable (since it contains very private data?) === niemeyer_ [n=niemeyer@200.138.52.87] has joined #launchpad === jinty [n=jinty@205.134.224.215] has joined #launchpad [12:46] (or is he emailing the results instead of sticking them in the Librarian?) === stub waits for his revlib cleanup to finish [12:48] Current one in my branch is guessable and needs to be fixed. Don't know about the updated version yet === RWG [n=RWGraphi@69.177.65.86] has joined #launchpad === RWG [n=RWGraphi@69.177.65.86] has left #launchpad ["Connection] === spiv [n=andrew@adsl-66-203.swiftdsl.com.au] has joined #launchpad [12:53] stub, both are guessable. jane wants them guessable. what should we do? [12:55] kiko: They can't be guessable until we work out how to put security into the Librarian and implement it. The only place we can put a secret at the moment is the filename, so any private data going into the Librarian *must* have a strongly unguessable filename. [12:56] Jane or marileze or whoever sends the files to the producer will need to manually rename it before resending it if necessary. [12:57] stub, can you email jane directly and raise this concern? at any rate, I think this will have to be dealt with next week.. jane really wants them to run this week === lamont__ [n=lamont@129.19.2.8] has joined #launchpad [12:59] It will be fixed today and merged in. I can't run the export until it s done. There is no way I'm going to create a permanent URL containing the shipping addresses of 20,000 geeks incudeing a fair number of privacy nuts and make it publicly available on the web. There is currently no alternative. === Virtuall[BZA] [n=virtuall@who.is.virtuall.info] has joined #launchpad [01:01] stub, whatever -- negotiate with the client, is all I ask. [01:01] she's not a lax customer either [01:01] kiko: There is no negotiation. We cannot do it. It would be illegal in most countries. [01:02] you're not listening.. :) [01:02] I am. If I wait until Jane is online and tell her the problem *before* fixing it, there will be no shipit run this week. If I fix it now, there will be. [01:03] dude... we are releasing _next_ week :-) [01:03] I agree you don't need to wait for her; I am pointing out however that this will need to be discussed with her, because she already asked salgado to change the filename to something less obscure. [01:04] kiko: So there will be no test shippit run this week, and I still will not do the export until it is fixed. [01:04] *My* address is in that list. [01:04] ah. test. :-P [01:06] night all [01:07] night [01:16] kiko: So shall I email Jane saying 'This is the situation, there is no alternative, and it would be fixed already except Kiko wants Jane to be aware of the problem before we fix it for no particular reason since there is no choice or decision to be made', or 'This is the issue, which I have fixed' [01:18] stub, I already conceded your point above -- do the fix, and notify her of the issue. [01:19] kiko: ok ;) [01:19] bah - I read that sentance three times and missed 'don't need to wait for her' each time ;-P [01:20] Weee... utilities/library-relink.py supposedly just saved me 2GB of a 2.7GB revlib [01:23] I feel like crying when baz gives me conflicts in files I didn't tough [01:23] touch either [01:24] Yer - I got that on a feature branch last night. I typed 'baz undo' and went to bed to will be having fun later today ;-/ [01:25] kiko: during merg e?> === eruin slaps kiko discreetly with a search tool while making duck-like sounds [01:27] lifeless, yeah, during merge [01:27] I'm also getting the weirdest thing [01:28] -- {arch}/launchpad/launchpad--devel/launchpad--devel--0/rocketfuel@canonical.com/patch-log/patch-2170 [01:28] lifeless, any clue what that is? [01:29] Bah - I think salgado broke the sampledata on that branch so some build tests are failing during the cherry pick ;-/ [01:30] oh, gross [01:30] lifeless: I might have to roll out a branch where some of the tests are failing due to sampledata issues [01:30] man, I'm really baz-fucked today [01:35] lifeless? [01:41] kiko: me too [01:41] 128 conflicts [01:41] naaaice [01:41] night all === sabdfl [n=mark@pdpc/supporter/silver/sabdfl] has left #launchpad [] [01:42] I got only 3 [01:42] maybe I should just retire this branch [02:11] 00:09:02 INFO lock /var/lock/launchpad-poimport.lock already exists, exiting [02:11] stub, that message is happening quite often, perhaps we should increase the interval with which it runs? [02:12] kiko: That would make a longer possible delay between someone uploading a file and it being imported. It isn't an issue except we are running it without '-q' at the moment, on Carlos' request [02:13] Might be better to reduce the verbosity of that message to 'DEBUG' ? [02:14] Bah - crontab doesn't know the output it is emailing is utf-8 encoded ;-/ [02:14] yeah, hmmm [02:31] lifeless, ping [02:31] matsubara: ? [02:31] kiko: pong [02:31] lifeless, could you help me solve this: https://launchpad.net/products/launchpad/+bug/750 ? [02:32] lifeless, do you know what happened to needsSyncReview? [02:32] ? [02:33] needsSyncReview is/was a flag used in the product series workflow by the importd team, which is currently ddaa [02:36] kiko: Do you happen to know if salgado is retricting shipit order information to ASCII at input time? [02:41] stub, yes, for everything (but the name originally -- it's now for everything, period) [02:41] kiko: And where are the shipit tests living? [02:41] there are both functional doc and pagetests [02:41] matsubara: ok. There is still code in the export that is stripping accented characters, which is dangerous because it is lossy. I'll remove it. [02:41] matsubara: But where. I can't find them ;) [02:42] doc/shipit.txt? [02:42] matsubara: Ta. I need glasses. [02:42] also standalone/xx-shipit-* [02:43] lifeless, do you know why the flag is missing? [02:43] lifeless, or if it was database-backed? [02:43] matsubara: I do not recall, sorry === rbelem [n=rodrigo@200.246.97.164] has joined #launchpad [03:01] kiko, remember to close 538 === tritium [n=michael@pcp0011975002pcs.sandia01.nm.comcast.net] has joined #launchpad === interalia [n=interali@adsl-60-232.swiftdsl.com.au] has joined #launchpad === rbelem_ [n=rodrigo@200.246.97.164] has joined #launchpad [05:19] Merge to rocketfuel@canonical.com/launchpad--devel--0: r=kiko Fix for bugs 2468 and 2467: System error when targeting a fix for a release, when no source package is specified, and System error when requesting fix in a distribution without specifying a source package. Unifies the way BugTask target names are rendered throughout Launchpad, making it consistent and ensuring we use a single codepath. Adds a test for bug 2467; pending a test for bug 2468. Patch === philiKON [n=philipp@222.70.121.120] has joined #launchpad [05:35] is there someone here who can give me access to https://launchpad.net/products/zope/+series/zope3.1/+pots/zope/+upload ? [05:35] i'm the maintainer of the zope translations [05:35] uploading a POT used to work, no idea why it doesn't anymore [05:35] get a "Forbidden" now [05:38] spiv: ping [05:41] philiKON: I'm not sure. [05:42] carlos does not seem to be around right now [05:42] that's ok, i'll wait [05:42] and hes Da Man for this [05:42] ok :) [05:43] philiKON: maybe because you aren't listed as registrant of zope? [05:44] (or belong to a team listed as the registrant [05:44] jamesh, i'm the team administrator [05:44] https://launchpad.net/people/zope3-dev/+members [05:45] for some reason, "mohsen" is listed as the owner of https://launchpad.net/products/zope/+series/zope3.1/+pots/zope though [05:45] philiKON: sure, but https://launchpad.net/products/zope shows the registrant as stub [05:45] maybe stub knows :) [05:55] stub: is there any reason you are listed as owner of https://launchpad.net/products/zope rather than the zope3-dev team? [05:56] Because I registered it? And the zope3-dev team doesn't necessarily have anything to do with Zope2, which will be a separate product series? [05:57] I have no ideas what rights it conveys besides setting metadata on the product and series === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad [05:58] I wonder why philiKON used to be able to upload a template then [05:59] i think i created the zope3.1 series [06:00] https://launchpad.net/products/zope/+series/zope3.1/+pots/zope is owned by "mohsen" though. no idea why. [06:00] lifeless, I was approved as a member many months ago, before we started using launchpad. Who approves the proposed members of "Ubuntu Members"? [06:00] i definitely remember uploading the first POT [06:01] tritium: mdz I would presume [06:01] or any of the CC [06:01] lifeless, ok, thanks [06:01] you too, ajmitch [06:02] speaking of zope, how would I get a team renamed? [06:03] since I in my ubuntu-centric ways registered a zope team on launchpad, intended for ubuntu & debian packaging === bradb_ [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad === bradb_ [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has left #launchpad [] [06:05] ajmitch, we might want to merge that with the zope3-dev team... [06:05] i created the zope3-dev team out of my zope3 developer-centric view :) [06:05] right :) [06:06] the debian/ubuntu team handles zope 2.x & 3.x packaging [06:06] hah [06:06] is Five in ubuntu/debian yet? [06:06] bob2, well, it is through zope2.8 [06:06] five 1.0 is part of zope 2.8 [06:06] oh, great [06:07] I'm happy to change ownership of the Zope product and projects to a suitable team [06:08] 'five' ? [06:08] heh [06:08] Zope 2 + 3 [06:08] erk [06:08] lifeless: brings some zope3 things to zope2 [06:08] why not just 'zope' [06:08] fun stuff :) [06:08] if i can be an admin of 'zope', i would vote for 'zope' [06:08] man, thats gonna be fun when z4 comes out, 'nine' [06:08] then we can move people over from 'zope3-dev' to 'zope' slowly... [06:09] lifeless, there won't be a z4... hopefully [06:09] maybe rename the existing zope team to pkg-zope, as it is in debian :) [06:09] How about you create a zope-admins team philiKON and I change ownership to that? [06:09] stub, phew, that would be a lot of teams then. [06:09] stub, but ok [06:10] Teams can be members of teams. Lots of rope for everyone! [06:10] ah, yeah :) === ajmitch should really tweak .procmailrc to sort ozzope mail into a separate folder [06:11] You probably just want zope-admins and zope-developers (or zope) for the product side. [06:11] lifeless: the CC deals with approving Members [06:11] right now we have 'zope' and 'zope3-dev' [06:11] And the distro stuff should be seperate teams probably once members can automatically upload new packages into Ubuntu Grumpy Groundhog. [06:11] lifeless: I deal with developers [06:12] mdz: ah righ [06:12] i guess we want to end up with 'zope-dev', 'zope-admin' and 'pkg-zope'...? [06:12] 't' [06:12] stub: the distro stuff is useful being separate now for bug assignment [06:12] ajmitch: mmm, you have 'upstream' and 'distrorelease' for that [06:12] true [06:12] philiKON: You could collapse 'zope-dev' and 'zope-admin' into one team if you don't mind giving full control over everything to eveyone ;) [06:13] nah, having them separate is better [06:13] stub, can teams be renamed? [06:13] mdz, should I just wait for the CC to review the proposed members, or ping somebody? [06:13] According to the spec, yes. === stub checks reality [06:13] tritium: if they were approved at a CC meeting but not processed in launchpad yet, then I'd say poke someone [06:14] stub, i propose to rename "zope3-dev" to just "zope-dev" and "zope" to "pkg-zope", like ajmitch suggested [06:14] mdz, thanks. I will, then. [06:14] Bah - there is no team rename in there. Thankfully the DBA is online... [06:15] stub, i created the 'zope-admin' team. would be great if you could give ownership of the zope package to that team [06:16] Renames are done [06:16] ajmitch, does anybody from the package guys need to be in this zope-admin team? [06:16] ah, cool [06:16] thanks [06:16] Extra points for someone creating a 16x16 icon for the emblem... [06:17] philiKON: probably not, afaik [06:17] ajmitch, ok... lemme know if that becomes the case [06:17] what does the zope-admin team do? :) [06:18] zope-admins now owns the zope product [06:18] be the owner of the 'zope' project [06:18] right [06:18] lifeless: pong [06:18] we'll apply if needed then [06:18] Change the product description, create new product series, that sort of stuff [06:18] stub: thanks for the rename [06:18] spiv: whats a good exception for 'cannot add FOO to container BAR, FOO is already present' [06:21] Hmm. Probably make an AlreadyExistsError? [06:21] yah, so there is not top level one [06:21] thanks [06:21] rorrEyeK ? [06:21] Probably a subclass of ValueError [06:22] I'm not sure about that. [06:22] works for me, TODOing it - thanks [06:22] Do you really want random "except ValueError:" clauses catching this? [06:23] noodle time [06:23] Mmm.... noodles.... [06:26] ajmitch, stub, you guys know what's up with this team: https://launchpad.net/people/zope3-dev-zope ? === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad [06:28] philiKON: That is actually a person. The zope3 developers mailing list email address must have gotten sucked in an an account created. [06:28] ah === stub nukes it [06:35] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] ShipIt paranoia updates (patch-2594: stuart.bishop@canonical.com) [07:05] whilst you are nuking stuff [07:05] how octopus-like are the sprint ? [07:05] (s) [07:10] dunno ;-) [07:11] Doesn't look bad. Just a cluster of three tables. [07:11] care to nuke the 'test print one' [07:12] Merge to rocketfuel@canonical.com/launchpad--production--1.35: Merge ShipIt export into production (patch-8: guilherme.salgado@canonical.com, stuart.bishop@canonical.com, rocketfuel@canonical.com) [08:22] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Add shipit indexes (patch-2595: stuart.bishop@canonical.com) === carlos [n=carlos@243.Red-83-47-24.staticIP.rima-tde.net] has joined #launchpad [09:04] morning [09:04] stub, hi [09:04] stub, the language pack script is using the db as read only [09:04] am I able to use commit in that situation? [09:05] carlos: yes. [09:05] oh! [09:06] ok, didn't know that, then I will commit after every pofile export [09:06] carlos: You can start abusing it again if you want - the upgrade I was doing has finished. [09:06] ok [09:06] thanks [09:06] carlos: I had to kill the process because I didn't notice what was happening until half way through [09:12] stub, added a commit and running the script now. Could you confirm if it's enough? [09:13] stub, btw, I think there is something wrong with the change you did to prevent that poimport fail more than once per day with a file [09:14] stub, we have more than 500 pofiles that are not being imported and I don't see anything in our logs that indicates that those pofiles are giving us problems [09:14] carlos: Shall I nuke the history and see what happens? [09:14] stub, yes, please [09:17] carlos: https://chinstrap.ubuntu.com/~dsilvers/paste/filenRPozP.html [09:18] cache nuked [09:19] stub, thank you [09:19] let's se what happens... [09:24] man, launchpad is sure taking long to upload my zope3.1 POT... === GoRoDeK [n=gorodek@p5083E981.dip.t-dialin.net] has joined #launchpad === Virtuall[BZA] [n=virtuall@who.is.virtuall.info] has joined #launchpad [09:29] philiKON, when did you upload it? [09:29] 3 hours ago maybe [09:31] philiKON, I cannot check it now, but I detected some problems with the import queue, debugging it atm [09:34] I might have interrupted that import - I had the system down for about 30 minutes. [09:37] stub, should i just resubmit? [09:37] philiKON: I don't know ;) Carlos? [09:38] hmm, I'm not sure === sabdfl [n=mark@host217-37-231-22.in-addr.btopenworld.com] has joined #launchpad [09:38] stub, please, could you execute SELECT ptn.name, pt.rawimportstatus from potemplatename ptn, potemplate pt where pt.potemplatename=ptn.id and ptn.name like 'zope'; ? [09:39] 3 entries, all with rawimportstatus==3 [09:39] that means that the import is done [09:39] philiKON, could you confirm, please? [09:40] carlos, ok. how do i do that? i have no idea what changed in the POT after the last upload (i just know *that* it changed) [09:41] Good morning everybody [09:41] philiKON, Project-Id-Version: Development/Revision: 38234/Branch: Zope-3.1 [09:41] philiKON, is that one? [09:41] or that's the old one? [09:41] sivang, morning [09:42] carlos, lemme check [09:42] carlos, looks like the new one [09:43] carlos, thanks [09:43] philiKON, cool [09:43] I did nothing ;-) but you are welcome === dand [n=dand@gw.datagroup.ro] has joined #launchpad [09:58] Marning [10:04] stub, ok, seems like the changes you did are the problem here [10:05] stub, the script is importing files from Wednesday now [10:05] ok. probably just a logic fault in the 'recently seen' code. [10:05] hi [10:08] carlos: I've scheduled a daily deletion of the cache, which should last until we can have a closer look at it. [10:08] yo stub [10:08] Review my branch bitch it is growing hair! [10:08] did you get the shipit export crack sorted? [10:08] stub, ok, thank you [10:08] Still working on shipit [10:08] stub: that's kinda fitting, coming from you [10:08] stub: i had a thought... export to a place on the filesystem [10:09] a directory given in the config [10:09] and point apache ,with auth at it [10:09] Oh... exports are sorted for now. Although we should refactor to not use the Librarian in this case I think. [10:10] I'm trying to rollout the updated shipit stuff to production [10:11] Or implement authorization into the Librarian somehow. === thebigearl [n=thebigea@dialin-80-228-157-042.ewe-ip-backbone.de] has joined #launchpad [10:13] #ubuntuusers [10:13] oops... sry === Jonex [n=Jonex@80.65.200.134] has joined #launchpad [10:31] SteveA, spiv hi, around? [10:32] hello carlos [10:32] SteveA, spiv http://librarian.launchpad.net/560358/560391/lSkFwO4AG0ocgPLZEaZ8JaScmVg.txt [10:32] We still have problems with librarian... [10:33] I can implement a workaround for that with a try/except and doing a full export instead of using the cache from librarian [10:33] but that will hide that problem [10:33] carlos: that's an isolated traceback [10:33] it doesn't tell me what was running [10:34] spiv: ping [10:34] SteveA, It came from a .po export request [10:34] the failure is when we fetch a file from librarian [10:34] and, this is a file that was recently added? [10:35] not sure [10:35] but spiv already checked the code and we have the needed commits [10:36] so in theory is not a transaction problem if that's what you are thinking on [10:36] stub: is commit() synchronous? [10:36] spiv is aware already of that bug and we don't see where is the problem exactly... [10:36] well [10:36] my question is if I can "hide" that problem [10:36] eh? [10:37] when spiv and i talked a while ago, we have a few ideas of what might be the root of the problem [10:37] or what should I do so users don't get this problem [10:37] and spiv was going to work on finding out which of the ideas is correct [10:37] SteveA, oh! didn't know it [10:37] stub: when in python i say commit(), does that call block until the data is in the "current committed data for all threads" on the postgres server? === jinty [n=jinty@205.134.224.215] has joined #launchpad [10:38] SteveA: So I'm told. [10:39] carlos: can you try putting a try/except around the call to the librarian in pofile.py, and if there's a LookupError, then log a warning, sleep for 1s, try again [10:39] I don't think spiv has tried lowering the transaction isolation a notch which would be safe and probably solve this [10:40] SteveA, Is that better than just request a full export? [10:40] yes [10:40] it also tells us when such an error has occured [10:40] so we can keep investigating it [10:41] stub: my worry about doing that is we may never find the cause of the problem [10:41] SteveA, I mean, log the warning and do a full export so if the error persists the user will get the file... [10:41] SteveA, a full export does not depend on librarian [10:41] If it solves it it tells us a lot about the cause of the problem. [10:42] well, it does but to feed it not to retrieve anything [10:43] stub: would you lower the isolation level for the librarian, for the exporter, or both? [10:43] SteveA: The Librarian [10:43] carlos: okay. [10:43] stub: it's tough though, beacuse all we will see is the absense of problems, not problems being solved. [10:44] still, provided carlos is logging this, we can see the frequency of errors, and try this out [10:44] without shitting on things [10:44] SteveA: It will mean that *yes*, the commit is happening in the export and *yes* the commit is visible to the Librarian. Which means either the Librarian has a transaction issue (not resetting the transaction at the start of the request). [10:45] stub: sure, so i'm saying, let's get carlos to make this change, watch the logs for a while, then lower the isolation level, and watch the logs for a while. [10:45] and note the differences. [10:45] c/carlos/spiv [10:46] oh [10:46] stub, no, it's my work :-P [11:04] stub, is the commit that I added enough to fix the lock problem you told me this morning? [11:05] carlos: Dunno ;) [11:05] carlos: Should be [11:05] ok [11:06] The easiest way for me to tell could break your export run again, so I won't do that just yet ;) [11:06] What is the correct way to invoke your superclass' __init__ ? [11:06] it it simply MySuperClass.__init__(self) [11:06] or is there some more 'correct' solution? [11:06] If you are a classic class, yes. [11:07] I'm a __metaclass__ = type [11:07] Kinnison: are you intending your class to be used in a crazy heap of mixins? [11:07] do you have a single base class? [11:07] no [11:07] yes [11:07] then that is the correct way [11:07] It's a very simple abstractparent ==> (child1, child2) heirarchy [11:07] good [11:08] then use what you wrote [11:08] okay [11:08] thanks [11:08] authserver down? [11:09] stub: i'm seeing a result ordering issue in shipit code [11:09] SteveA: Is there a method run on class construction? [11:09] https://chinstrap.ubuntu.com/~dsilvers/paste/file2tLS5P.html [11:10] Kinnison: __init__ [11:10] SteveA: I want to register each of the child classes in an array [11:10] Kinnison: what do you mean "class construction" [11:10] lifeless: that's instance construction [11:10] Kinnison: there are such things [11:10] Kinnison: don't mess with them [11:10] SteveA: I did some fixes to fmt:text-to-html that should fix https://launchpad.net/products/launchpad/+bug/1749 [11:10] do it by hand [11:10] okay, so I should just register them by hand in the module level code? [11:10] yes [11:10] sure [11:10] thanks [11:10] it uses 77% less regular expressions [11:10] anything more contrived gets scary [11:10] Kinnison: then not that I know of, you'd have to hook into the module loader.. but __new__ may be close to what you want, which is run to create instances, or just put the stuff you want in the class decl.. [11:10] except for gurus [11:10] class Foo: [11:11] who love that shit [11:11] something_here_is_run_at_'class construction' [11:11] SteveA: Looks like the usual [11:11] lifeless: i'd be inclined to use a class advisor [11:11] lifeless: but, really... it is too complex for what Kinnison needs [11:11] SteveA: I don't know that term [11:11] lifeless: like implements(IFoo) [11:11] SteveA: nor what Kinnison needs, was just answering the question ;) [11:12] SteveA: oh right, just code executed during class parsing [11:12] i came up with the idea when jim said something was a nice idea but couldn't be done ;-) i showed it to PJE who coined the term 'class advisor' and improved the implementation and added to his PEAK library. jamesh wrote a weblog entry on them [11:12] sweet [11:12] lifeless: code executed during class parsing which changes the metaclass [11:12] and remembers the original metaclass [11:13] SteveA: decorates the metaclass ? [11:13] then uses the metaclass to hook into offering some advice [11:13] kind of [11:13] gone again.. [11:13] bye-for-now [11:13] it isn't really a decorator in the sense we usually use the term [11:13] i think [11:14] stub: usual? [11:14] lifeless: http://blogs.gnome.org/view/jamesh/2005/09/08/0 <- that's my understanding of the code [11:16] jamesh: the rules you give for determining the true metaclass are i think slightly simplified [11:16] then again, they aren't documented properly anywhere except in the C source code that does this stuff [11:16] even GvR generally documents them wrongly [11:16] fortunately PJE is kinda pedantic on these things ;-) [11:17] i think the simplified version is better for a blog article anyway === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad [11:19] SteveA: Someone forgot to put in an orderBy argument so we get indeterminate SQLObject result ordering [11:20] and it isn't warned [11:20] because the test uses a list comprehension [11:21] i'll let salgado fix it in a few hours [11:21] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Split a shipit db patch in two so it can be run seperatly (patch-2596: stuart.bishop@canonical.com) [11:21] unless it's going to crap all over pqm merges [11:41] I am creating some "context" control classes for the uploader. They allow the uploader to decide what tests are appropriate for an upload in a given context. E.g. for uploads from the buildds, we don't check for signatures. === zyga [n=zyga@2-mi2-1.acn.waw.pl] has joined #launchpad [11:42] Now, I could just set up things like in __init__ do self.checksigs = True/False [11:42] or I could have effectively static properties [11:42] so that I can docstring them [11:42] what is the best style? === _Rappy_ [n=hunt-pre@dsl-253-122.monet.no] has joined #launchpad [11:59] SteveA: ^^ ? [12:00] Kinnison: hello [12:01] Kinnison: can you possibly find a different term than "context" ? [12:01] or a more specific term? [12:01] It's an UploadContext [12:02] Or rather, one of InsecureUploadContext and BuildDaemonUploadContext [12:02] okay. just, don't use the variable name 'context' anywhere [12:02] Not even in process-upload.py ? [12:02] you have an OO design choice here [12:02] no not even there [12:02]