[12:25] <kiko> heya stub
[12:26] <stub> yo
[12:29] <lifeless> yoiifcation
[12:31] <kiko> how goes it
[12:31] <kiko> hey sabdfl
[12:32] <sabdfl> kiko: excellent thanks. you?
[12:32] <kiko> pretty good. glad to see you back in the london seat! had a good rest?
[12:33] <ajmitch> hi
[12:34] <stub> Is Steve's navigation work ready for production rollout Tuesday?
[12:34] <kiko> stub, I need to merge them in to test, first
[12:34] <kiko> it's a pretty big change
[12:35] <stub> 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?)
[12:46] <stub> (or is he emailing the results instead of sticking them in the Librarian?)
[12:48] <stub> Current one in my branch is guessable and needs to be fixed. Don't know about the updated version yet
[12:53] <kiko> stub, both are guessable. jane wants them guessable. what should we do?
[12:55] <stub> 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] <stub> Jane or marileze or whoever sends the files to the producer will need to manually rename it before resending it if necessary.
[12:57] <kiko> 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
[12:59] <stub> 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.
[01:01] <kiko> stub, whatever -- negotiate with the client, is all I ask.
[01:01] <kiko> she's not a lax customer either
[01:01] <stub> kiko: There is no negotiation. We cannot do it. It would be illegal in most countries.
[01:02] <kiko> you're not listening.. :)
[01:02] <stub> 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] <Nafallo> dude... we are releasing _next_ week :-)
[01:03] <kiko> 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] <stub> 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] <stub> *My* address is in that list.
[01:04] <Nafallo> ah. test. :-P
[01:06] <mpt> night all
[01:07] <stub> night
[01:16] <stub> 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] <kiko> stub, I already conceded your point above -- do the fix, and notify her of the issue.
[01:19] <stub> kiko: ok ;)
[01:19] <stub> bah - I read that sentance three times and missed 'don't need to wait for her' each time ;-P
[01:20] <stub> Weee... utilities/library-relink.py supposedly just saved me 2GB of a 2.7GB revlib
[01:23] <kiko> I feel like crying when baz gives me conflicts in files I didn't tough
[01:23] <kiko> touch either
[01:24] <stub> 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] <lifeless> kiko: during merg e?>
[01:27] <kiko> lifeless, yeah, during merge
[01:27] <kiko> I'm also getting the weirdest thing
[01:28] <kiko> --<EMAIL_ADDRESS>[01:28] <kiko> lifeless, any clue what that is?
[01:29] <stub> Bah - I think salgado broke the sampledata on that branch so some build tests are failing during the cherry pick ;-/
[01:30] <kiko> oh, gross
[01:30] <stub> lifeless: I might have to roll out a branch where some of the tests are failing due to sampledata issues
[01:30] <kiko> man, I'm really baz-fucked today
[01:35] <kiko> lifeless?
[01:41] <sabdfl> kiko: me too
[01:41] <sabdfl> 128 conflicts
[01:41] <sabdfl> naaaice
[01:41] <sabdfl> night all
[01:42] <kiko> I got only 3
[01:42] <kiko> maybe I should just retire this branch
[02:11] <kiko> 00:09:02 INFO    lock /var/lock/launchpad-poimport.lock already exists, exiting
[02:11] <kiko> stub, that message is happening quite often, perhaps we should increase the interval with which it runs?
[02:12] <stub> 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] <stub> Might be better to reduce the verbosity of that message to 'DEBUG' ?
[02:14] <stub> Bah - crontab doesn't know the output it is emailing is utf-8 encoded ;-/
[02:14] <kiko> yeah, hmmm
[02:31] <matsubara> lifeless, ping
[02:31] <lifeless> matsubara: ?
[02:31] <lifeless> kiko: pong
[02:31] <matsubara> lifeless, could you help me solve this: https://launchpad.net/products/launchpad/+bug/750 ?
[02:32] <matsubara> lifeless, do you know what happened to needsSyncReview?
[02:32] <lifeless> ?
[02:33] <lifeless> needsSyncReview is/was a flag used in the product series workflow by the importd team, which is currently ddaa
[02:36] <stub> kiko: Do you happen to know if salgado is retricting shipit order information to ASCII at input time?
[02:41] <matsubara> stub, yes, for everything (but the name originally -- it's now for everything, period)
[02:41] <stub> kiko: And where are the shipit tests living?
[02:41] <matsubara> there are both functional doc and pagetests
[02:41] <stub> 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] <stub> matsubara: But where. I can't find them ;)
[02:42] <matsubara> doc/shipit.txt?
[02:42] <stub> matsubara: Ta. I need glasses.
[02:42] <matsubara> also standalone/xx-shipit-*
[02:43] <matsubara> lifeless, do you know why the flag is missing?
[02:43] <matsubara> lifeless, or if it was database-backed?
[02:43] <lifeless> matsubara: I do not recall, sorry
[03:01] <matsubara> kiko, remember to close 538
[05:19] <dilys> Merge to<EMAIL_ADDRESS>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
[05:35] <philiKON> is there someone here who can give me access to https://launchpad.net/products/zope/+series/zope3.1/+pots/zope/+upload ?
[05:35] <philiKON> i'm the maintainer of the zope translations
[05:35] <philiKON> uploading a POT used to work, no idea why it doesn't anymore
[05:35] <philiKON> get a "Forbidden" now
[05:38] <lifeless> spiv: ping
[05:41] <lifeless> philiKON: I'm not sure.
[05:42] <lifeless> carlos does not seem to be around right now
[05:42] <philiKON> that's ok, i'll wait
[05:42] <lifeless> and hes Da Man for this
[05:42] <philiKON> ok :)
[05:43] <jamesh> philiKON: maybe because you aren't listed as registrant of zope?
[05:44] <jamesh> (or belong to a team listed as the registrant
[05:44] <philiKON> jamesh, i'm the team administrator
[05:44] <philiKON> https://launchpad.net/people/zope3-dev/+members
[05:45] <philiKON> for some reason, "mohsen" is listed as the owner of https://launchpad.net/products/zope/+series/zope3.1/+pots/zope though
[05:45] <jamesh> philiKON: sure, but https://launchpad.net/products/zope shows the registrant as stub
[05:45] <jamesh> maybe stub knows :)
[05:55] <jamesh> stub: is there any reason you are listed as owner of https://launchpad.net/products/zope rather than the zope3-dev team?
[05:56] <stub> 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] <stub> I have no ideas what rights it conveys besides setting metadata on the product and series
[05:58] <jamesh> I wonder why philiKON used to be able to upload a template then
[05:59] <philiKON> i think i created the zope3.1 series
[06:00] <philiKON> https://launchpad.net/products/zope/+series/zope3.1/+pots/zope is owned by "mohsen" though. no idea why.
[06:00] <tritium> 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] <philiKON> i definitely remember uploading the first POT
[06:01] <lifeless> tritium: mdz I would presume
[06:01] <ajmitch> or any of the CC
[06:01] <tritium> lifeless, ok, thanks
[06:01] <tritium> you too, ajmitch
[06:02] <ajmitch> speaking of zope, how would I get a team renamed?
[06:03] <ajmitch> since I in my ubuntu-centric ways registered a zope team on launchpad, intended for ubuntu & debian packaging
[06:05] <philiKON> ajmitch, we might want to merge that with the zope3-dev team...
[06:05] <philiKON> i created the zope3-dev team out of my zope3 developer-centric view :)
[06:05] <ajmitch> right :)
[06:06] <ajmitch> the debian/ubuntu team handles zope 2.x & 3.x packaging
[06:06] <bob2> hah
[06:06] <bob2> is Five in ubuntu/debian yet?
[06:06] <philiKON> bob2, well, it is through zope2.8
[06:06] <philiKON> five 1.0 is part of zope 2.8
[06:06] <bob2> oh, great
[06:07] <stub> I'm happy to change ownership of the Zope product and projects to a suitable team
[06:08] <lifeless> 'five' ?
[06:08] <philiKON> heh
[06:08] <stub> Zope 2 + 3
[06:08] <lifeless> erk
[06:08] <bob2> lifeless: brings some zope3 things to zope2
[06:08] <philiKON> why not just 'zope'
[06:08] <ajmitch> fun stuff :)
[06:08] <philiKON> if i can be an admin of 'zope', i would vote for 'zope'
[06:08] <lifeless> man, thats gonna be fun when z4 comes out, 'nine'
[06:08] <philiKON> then we can move people over from 'zope3-dev' to 'zope' slowly...
[06:09] <philiKON> lifeless, there won't be a z4... hopefully
[06:09] <ajmitch> maybe rename the existing zope team to pkg-zope, as it is in debian :)
[06:09] <stub> How about you create a zope-admins team philiKON and I change ownership to that?
[06:09] <philiKON> stub, phew, that would be a lot of teams then.
[06:09] <philiKON> stub, but ok
[06:10] <stub> Teams can be members of teams. Lots of rope for everyone!
[06:10] <philiKON> ah, yeah :)
[06:11] <stub> You probably just want zope-admins and zope-developers (or zope) for the product side.
[06:11] <mdz> lifeless: the CC deals with approving Members
[06:11] <philiKON> right now we have 'zope' and 'zope3-dev'
[06:11] <stub> And the distro stuff should be seperate teams probably once members can automatically upload new packages into Ubuntu Grumpy Groundhog.
[06:11] <mdz> lifeless: I deal with developers
[06:12] <lifeless> mdz: ah righ
[06:12] <philiKON> i guess we want to end up with 'zope-dev', 'zope-admin' and 'pkg-zope'...?
[06:12] <lifeless> 't'
[06:12] <ajmitch> stub: the distro stuff is useful being separate now for bug assignment
[06:12] <lifeless> ajmitch: mmm, you have 'upstream' and 'distrorelease' for that
[06:12] <ajmitch> true
[06:12] <stub> 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] <philiKON> nah, having them separate is better
[06:13] <philiKON> stub, can teams be renamed?
[06:13] <tritium> mdz, should I just wait for the CC to review the proposed members, or ping somebody?
[06:13] <stub> According to the spec, yes.
[06:13] <mdz> tritium: if they were approved at a CC meeting but not processed in launchpad yet, then I'd say poke someone
[06:14] <philiKON> stub, i propose to rename "zope3-dev" to just "zope-dev" and "zope" to "pkg-zope", like ajmitch suggested
[06:14] <tritium> mdz, thanks.  I will, then.
[06:14] <stub> Bah - there is no team rename in there. Thankfully the DBA is online...
[06:15] <philiKON> stub, i created the 'zope-admin' team. would be great if you could give ownership of the zope package to that team
[06:16] <stub> Renames are done
[06:16] <philiKON> ajmitch, does anybody from the package guys need to be in this zope-admin team?
[06:16] <philiKON> ah, cool
[06:16] <philiKON> thanks
[06:16] <stub> Extra points for someone creating a 16x16 icon for the emblem...
[06:17] <ajmitch> philiKON: probably not, afaik
[06:17] <philiKON> ajmitch, ok... lemme know if that becomes the case
[06:17] <ajmitch> what does the zope-admin team do? :)
[06:18] <stub> zope-admins now owns the zope product
[06:18] <philiKON> be the owner of the 'zope' project
[06:18] <ajmitch> right
[06:18] <spiv> lifeless: pong
[06:18] <ajmitch> we'll apply if needed then
[06:18] <stub> Change the product description, create new product series, that sort of stuff
[06:18] <ajmitch> stub: thanks for the rename
[06:18] <lifeless> spiv: whats a good exception for 'cannot add FOO to container BAR, FOO is already present'
[06:21] <spiv> Hmm.  Probably make an AlreadyExistsError?
[06:21] <lifeless> yah, so there is not top level one
[06:21] <lifeless> thanks
[06:21] <stub> rorrEyeK ?
[06:21] <stub> Probably a subclass of ValueError
[06:22] <spiv> I'm not sure about that.
[06:22] <lifeless> works for me, TODOing it - thanks
[06:22] <spiv> Do you really want random "except ValueError:" clauses catching this?
[06:23] <lifeless> noodle time
[06:23] <stub> Mmm.... noodles....
[06:26] <philiKON> ajmitch, stub, you guys know what's up with this team: https://launchpad.net/people/zope3-dev-zope ?
[06:28] <stub> philiKON: That is actually a person. The zope3 developers mailing list email address must have gotten sucked in an an account created.
[06:28] <philiKON> ah
[06:35] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  ShipIt paranoia updates (patch-2594<EMAIL_ADDRESS>[07:05] <lifeless> whilst you are nuking stuff
[07:05] <lifeless> how octopus-like are the sprint ?
[07:05] <lifeless> (s)
[07:10] <stub> dunno ;-)
[07:11] <stub> Doesn't look bad. Just a cluster of three tables.
[07:11] <lifeless> care to nuke the 'test print one'
[07:12] <dilys> Merge to<EMAIL_ADDRESS>Merge ShipIt export into production (patch-8<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>[08:22] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Add shipit indexes (patch-2595<EMAIL_ADDRESS>[09:04] <carlos> morning
[09:04] <carlos> stub, hi
[09:04] <carlos> stub, the language pack script is using the db as read only
[09:04] <carlos> am I able to use commit in that situation?
[09:05] <stub> carlos: yes.
[09:05] <carlos> oh!
[09:06] <carlos> ok, didn't know that, then  I will commit after every pofile export
[09:06] <stub> carlos: You can start abusing it again if you want - the upgrade I was doing has finished.
[09:06] <carlos> ok
[09:06] <carlos> thanks
[09:06] <stub> carlos: I had to kill the process because I didn't notice what was happening until half way through
[09:12] <carlos> stub, added a commit and running the script now. Could you confirm if it's enough?
[09:13] <carlos> 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] <carlos> 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] <stub> carlos: Shall I nuke the history and see what happens?
[09:14] <carlos> stub, yes, please
[09:17] <stub> carlos: https://chinstrap.ubuntu.com/~dsilvers/paste/filenRPozP.html
[09:18] <stub> cache nuked
[09:19] <carlos> stub, thank you
[09:19] <carlos> let's se what happens...
[09:24] <philiKON> man, launchpad is sure taking long to upload my zope3.1 POT...
[09:29] <carlos> philiKON, when did you upload it?
[09:29] <philiKON> 3 hours ago maybe
[09:31] <carlos> philiKON, I cannot check it now, but I detected some problems with the import queue, debugging it atm
[09:34] <stub> I might have interrupted that import - I had the system down for about 30 minutes.
[09:37] <philiKON> stub, should i just resubmit?
[09:37] <stub> philiKON: I don't know ;) Carlos?
[09:38] <carlos> hmm, I'm not sure
[09:38] <carlos> 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] <stub> 3 entries, all with rawimportstatus==3
[09:39] <carlos> that means that the import is done
[09:39] <carlos> philiKON, could you confirm, please?
[09:40] <philiKON> 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] <sivang> Good morning everybody
[09:41] <carlos> philiKON, Project-Id-Version: Development/Revision: 38234/Branch: Zope-3.1
[09:41] <carlos> philiKON, is that one?
[09:41] <carlos> or that's the old one?
[09:41] <carlos> sivang, morning
[09:42] <philiKON> carlos, lemme check
[09:42] <philiKON> carlos, looks like the new one
[09:43] <philiKON> carlos, thanks
[09:43] <carlos> philiKON, cool
[09:43] <carlos> I did nothing ;-) but you are welcome
[09:58] <Kinnison> Marning
[10:04] <carlos> stub, ok, seems like the changes you did are the problem here
[10:05] <carlos> stub, the script is importing files from Wednesday now
[10:05] <stub> ok. probably just a logic fault in the 'recently seen' code.
[10:05] <SteveA> hi
[10:08] <stub> carlos: I've scheduled a daily deletion of the cache, which should last until we can have a closer look at it.
[10:08] <SteveA> yo stub
[10:08] <stub> Review my branch bitch it is growing hair!
[10:08] <SteveA> did you get the shipit export crack sorted?
[10:08] <carlos> stub, ok, thank you
[10:08] <stub> Still working on shipit
[10:08] <SteveA> stub: that's kinda fitting, coming from you
[10:08] <SteveA> stub: i had a thought... export to a place on the filesystem
[10:09] <SteveA> a directory given in the config
[10:09] <SteveA> and point apache ,with auth at it
[10:09] <stub> Oh... exports are sorted for now. Although we should refactor to not use the Librarian in this case I think.
[10:10] <stub> I'm trying to rollout the updated shipit stuff to production
[10:11] <stub> Or implement authorization into the Librarian somehow.
[10:13] <thebigearl> #ubuntuusers
[10:13] <thebigearl> oops... sry
[10:31] <carlos> SteveA, spiv hi, around?
[10:32] <SteveA> hello carlos
[10:32] <carlos> SteveA, spiv http://librarian.launchpad.net/560358/560391/lSkFwO4AG0ocgPLZEaZ8JaScmVg.txt
[10:32] <carlos> We still have problems with librarian...
[10:33] <carlos> 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] <carlos> but that will hide that problem
[10:33] <SteveA> carlos: that's an isolated traceback
[10:33] <SteveA> it doesn't tell me what was running
[10:34] <SteveA> spiv: ping
[10:34] <carlos> SteveA, It came from a .po export request
[10:34] <carlos> the failure is when we fetch a file from librarian
[10:34] <SteveA> and, this is a file that was recently added?
[10:35] <carlos> not sure
[10:35] <carlos> but spiv already checked the code and we have the needed commits
[10:36] <carlos> so in theory is not a transaction problem if that's what you are thinking on
[10:36] <SteveA> stub: is commit() synchronous?
[10:36] <carlos> spiv is aware already of that bug and we don't see where is the problem exactly...
[10:36] <SteveA> well
[10:36] <carlos> my question is if I can "hide" that problem
[10:36] <stub> eh?
[10:37] <SteveA> when spiv and i talked a while ago, we have a few ideas of what might be the root of the problem
[10:37] <carlos> or what should I do so users don't get this problem
[10:37] <SteveA> and spiv was going to work on finding out which of the ideas is correct
[10:37] <carlos> SteveA, oh! didn't know it
[10:37] <SteveA> 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?
[10:38] <stub> SteveA: So I'm told.
[10:39] <SteveA> 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] <stub> I don't think spiv has tried lowering the transaction isolation a notch which would be safe and probably solve this
[10:40] <carlos> SteveA, Is that better than just request a full export?
[10:40] <SteveA> yes
[10:40] <SteveA> it also tells us when such an error has occured
[10:40] <SteveA> so we can keep investigating it
[10:41] <SteveA> stub: my worry about doing that is we may never find the cause of the problem
[10:41] <carlos> SteveA, I mean, log the warning and do a full export so if the error persists the user will get the file...
[10:41] <carlos> SteveA, a full export does not depend on librarian
[10:41] <stub> If it solves it it tells us a lot about the cause of the problem.
[10:42] <carlos> well, it does but to feed it not to retrieve anything
[10:43] <SteveA> stub: would you lower the isolation level for the librarian, for the exporter, or both?
[10:43] <stub> SteveA: The Librarian
[10:43] <SteveA> carlos: okay.
[10:43] <SteveA> stub: it's tough though, beacuse all we will see is the absense of problems, not problems being solved.
[10:44] <SteveA> still, provided carlos is logging this, we can see the frequency of errors, and try this out
[10:44] <SteveA> without shitting on things
[10:44] <stub> 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] <SteveA> 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] <SteveA> and note the differences.
[10:45] <stub> c/carlos/spiv
[10:46] <stub> oh
[10:46] <carlos> stub, no, it's my work :-P
[11:04] <carlos> stub, is the commit that I added enough to fix the lock problem you told me this morning?
[11:05] <stub> carlos: Dunno ;)
[11:05] <stub> carlos: Should be
[11:05] <carlos> ok
[11:06] <stub> The easiest way for me to tell could break your export run again, so I won't do that just yet ;)
[11:06] <Kinnison> What is the correct way to invoke your superclass' __init__ ?
[11:06] <Kinnison> it it simply MySuperClass.__init__(self)
[11:06] <Kinnison> or is there some more 'correct' solution?
[11:06] <stub> If you are a classic class, yes.
[11:07] <Kinnison> I'm a __metaclass__ = type
[11:07] <SteveA> Kinnison: are you intending your class to be used in a crazy heap of mixins?
[11:07] <SteveA> do you have a single base class?
[11:07] <Kinnison> no
[11:07] <Kinnison> yes
[11:07] <SteveA> then that is the correct way
[11:07] <Kinnison> It's a very simple abstractparent ==> (child1, child2) heirarchy
[11:07] <SteveA> good
[11:08] <SteveA> then use what you wrote
[11:08] <Kinnison> okay
[11:08] <Kinnison> thanks
[11:08] <jamesh> authserver down?
[11:09] <SteveA> stub: i'm seeing a result ordering issue in shipit code
[11:09] <Kinnison> SteveA: Is there a method run on class construction?
[11:09] <SteveA> https://chinstrap.ubuntu.com/~dsilvers/paste/file2tLS5P.html
[11:10] <lifeless> Kinnison: __init__
[11:10] <Kinnison> SteveA: I want to register each of the child classes in an array
[11:10] <SteveA> Kinnison: what do you mean "class construction"
[11:10] <Kinnison> lifeless: that's instance construction
[11:10] <SteveA> Kinnison: there are such things
[11:10] <SteveA> Kinnison: don't mess with them
[11:10] <jamesh> SteveA: I did some fixes to fmt:text-to-html that should fix https://launchpad.net/products/launchpad/+bug/1749
[11:10] <SteveA> do it by hand
[11:10] <Kinnison> okay, so I should just register them by hand in the module level code?
[11:10] <SteveA> yes
[11:10] <Kinnison> sure
[11:10] <Kinnison> thanks
[11:10] <jamesh> it uses 77% less regular expressions
[11:10] <SteveA> anything more contrived gets scary
[11:10] <lifeless> 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] <SteveA> except for gurus
[11:10] <lifeless> class Foo:
[11:11] <SteveA> who love that shit
[11:11] <lifeless>     something_here_is_run_at_'class construction'
[11:11] <stub> SteveA: Looks like the usual
[11:11] <SteveA> lifeless: i'd be inclined to use a class advisor
[11:11] <SteveA> lifeless: but, really... it is too complex for what Kinnison  needs
[11:11] <lifeless> SteveA: I don't know that term
[11:11] <SteveA> lifeless: like implements(IFoo)
[11:11] <lifeless> SteveA: nor what Kinnison needs, was just answering the question ;)
[11:12] <lifeless> SteveA: oh right, just code executed during class parsing
[11:12] <SteveA> 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] <lifeless> sweet
[11:12] <SteveA> lifeless: code executed during class parsing which changes the metaclass
[11:12] <SteveA> and remembers the original metaclass
[11:13] <lifeless> SteveA: decorates the metaclass ?
[11:13] <SteveA> then uses the metaclass to hook into offering some advice
[11:13] <SteveA> kind of
[11:13] <lifeless> gone again..
[11:13] <lifeless> bye-for-now
[11:13] <SteveA> it isn't really a decorator in the sense we usually use the term
[11:13] <SteveA> i think
[11:14] <SteveA> stub: usual?
[11:14] <jamesh> lifeless: http://blogs.gnome.org/view/jamesh/2005/09/08/0 <- that's my understanding of the code
[11:16] <SteveA> jamesh: the rules you give for determining the true metaclass are i think slightly simplified
[11:16] <SteveA> then again, they aren't documented properly anywhere except in the C source code that does this stuff
[11:16] <SteveA> even GvR generally documents them wrongly
[11:16] <SteveA> fortunately PJE is kinda pedantic on these things ;-)
[11:17] <SteveA> i think the simplified version is better for a blog article anyway
[11:19] <stub> SteveA: Someone forgot to put in an orderBy argument so we get indeterminate SQLObject result ordering
[11:20] <SteveA> and it isn't warned
[11:20] <SteveA> because the test uses a list comprehension
[11:21] <SteveA> i'll let salgado fix it in a few hours
[11:21] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Split a shipit db patch in two so it can be run seperatly (patch-2596<EMAIL_ADDRESS>[11:21] <SteveA> unless it's going to crap all over pqm merges
[11:41] <Kinnison> 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.
[11:42] <Kinnison> Now, I could just set up things like in __init__ do self.checksigs = True/False
[11:42] <Kinnison> or I could have effectively static properties
[11:42] <Kinnison> so that I can docstring them
[11:42] <Kinnison> what is the best style?
[11:59] <Kinnison> SteveA: ^^ ?
[12:00] <SteveA> Kinnison: hello
[12:01] <SteveA> Kinnison: can you possibly find a different term than "context" ?
[12:01] <SteveA> or a more specific term?
[12:01] <Kinnison> It's an UploadContext
[12:02] <Kinnison> Or rather, one of InsecureUploadContext and BuildDaemonUploadContext
[12:02] <SteveA> okay.  just, don't use the variable name 'context' anywhere
[12:02] <Kinnison> Not even in process-upload.py ?
[12:02] <SteveA> you have an OO design choice here
[12:02] <SteveA> no not even there
[12:02] <SteveA> always uploadcontext or ucontext or something
[12:03] <Kinnison> okay
[12:03] <SteveA> it was very confusing reading 'request' in salgado's original shipit database classes
[12:03] <Kinnison> Fair enough
[12:03] <SteveA> so, the OO design choice is
[12:03] <SteveA> do you make your UploadContext classes express information about policy, or do you get them do implement policy
[12:04] <SteveA> that is, you can say
[12:04] <SteveA>   class UploadContext:
[12:04] <Kinnison> They are to express policy
[12:04] <SteveA>       checksigs = False  # the we trust all uploads cos we are on crack
[12:04] <SteveA> or you can say
[12:04] <SteveA>   class UploadContext:
[12:04] <Kinnison> The NascentUpload class will apply policy provided by a context object
[12:04] <SteveA>       def verify_upload(self, upload):
[12:05] <SteveA>           ... this implementation doesn't check the sig for the above reasons
[12:05] <SteveA>
[12:05] <Kinnison> class InsecureUploadContext:
[12:05] <Kinnison>     @property
[12:05] <SteveA> you could also have a single ContextPolicy class
[12:05] <SteveA> and make singleton instances of it
[12:05] <SteveA> to express the different variations in policy
[12:05] <Kinnison>     def check_sigs(self):
[12:05] <SteveA> if there are only a few of these
[12:05] <Kinnison>         """We check signatures on insecure uploads."""
[12:05] <Kinnison>         return True
[12:06] <SteveA> i suggest you have some classes, and use class attributes
[12:06] <SteveA> and define an interface IContextPolicy (or whatever)
[12:06] <SteveA> where you document the expected attributes
[12:06] <Kinnison> contexts need to verify their arguments though
[12:06] <Kinnison> E.g. The BuildDaemonUploadContext will verify that the process-upload instance was given a build-id to attach to
[12:07] <SteveA> this is a different thing than what you were asking originally
[12:07] <SteveA> i would need to understand how the parts fit together in order to make a recommendation about this
[12:07] <Kinnison> Okay
[12:08] <SteveA> but
[12:08] <SteveA> maybe start by writing the interfaces for the various moving parts
[12:08] <SteveA> and write a decent interface docstring for each
[12:08] <SteveA> so, you have your upload context part, and your process upload part
[12:08] <SteveA> that should help to communicate the larger picture
[12:08] <Kinnison> My NascentUpload stuff is what I was going to start writing next
[12:09] <Kinnison> because I imagined that as I try and apply a context to a NascentUpload it'll give me a chance to work out the best interface
[12:10] <SteveA> you can write in the docstring what you imaging the scope and responsibilities of an UploadContext are
[12:10] <SteveA> these things are not clear to me
[12:10] <Kinnison> yep, I'll do that
[12:10] <Kinnison> The doctests have some of this information in them already
[12:10] <Kinnison> I guess I need to migrate that to the docstrings
[12:11] <SteveA> okay
[12:11] <SteveA> perhaps i've been some help clarifying things
[12:11] <Kinnison> Yep
[12:11] <Kinnison> thanks
[12:18] <sivang> SteveA: so , I don't recall (after checking the logs) what book did you recommend for Zope, besides the "Web component development with Zope 3" or wasn't any other? :)
[12:19] <SteveA> i haven't read any of the books for learning zope3
[12:20] <SteveA> bob2 has, i think
[12:20] <SteveA> i know the authors of both books
[12:20] <SteveA> stephan's book is available online
[12:20] <SteveA> so, that's a good start
[12:20] <SteveA> it is a wiki site
[12:20] <SteveA> but you can buy the paper book too
[12:25] <sivang> k thanks
[12:30] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  rename uploader.py to poppyinterface.py in canonical.archivepublisher (patch-2597<EMAIL_ADDRESS>[12:41] <Kinnison> When a doctest is run, what is its CWD?
[12:45] <lifeless> Kinnison: reading between the lines, look at the gpg tests, they figure out where to find files
[12:46] <Kinnison> Right
[12:47] <lifeless> (the answer is, any, you don't (cant) know)
[12:48] <SteveA> Kinnison: i suggest to do the following: import a module.  inspect the module's __file__ attribute.  get files relative to that.
[12:48] <SteveA> we could have a open_file_from(module) or get_filename_from(module)
[12:48] <SteveA> if these are needed
[12:48] <Kinnison> from canonical.archivepublisher.tests import datadir
[12:49] <Kinnison> :-)
[12:49] <SteveA> yay
[12:53] <Kinnison> Hmm, interesting test system bug
[12:53] <Kinnison> if you run: python text.py -f --test="foobar"
[12:53] <Kinnison> where foobar matches some pagetest names too
[12:54] <Kinnison> then the pagetests are also run
[12:54] <Kinnison> but the story isn't run in its entirety
[12:54] <Kinnison> which causes failures
[12:55] <jordi> carlos: was Tagalog added to the database in the end?
[12:55] <jordi> (tl code)
[12:56] <carlos> jordi, no, I don't think so
[12:56] <carlos> I'm going to request a change to the DB so I will add that request too
[12:56] <SteveA> Kinnison: yes, known limitation in the pagetests
[12:56] <Kinnison> SteveA: this is very annoying
[12:56] <jordi> Plural-Forms is nplurals=2; plural=n>1;
[12:56] <Kinnison> can I simply give multiple --test= args?
[12:57] <SteveA> probably not
[12:57] <jordi> carlos: great. We have a few others in the queue, but we don't have reliable info yet.
[12:57] <SteveA> just run one, then run the other
[12:57] <Kinnison> but test startup is hideously expensive
[12:57] <SteveA> or start a wiki page / bug on what you want the test runner to do
[12:57] <carlos> jordi, send me it by email, please
[12:57] <jordi> sure
[12:58] <jordi> carlos: it's in the launchpad mailing list though
[12:58] <carlos> ok
[12:58] <jordi> Date: Fri, 23 Sep 2005 18:34:41 +0200
[01:00] <lifeless> theres a bug on ita laready
[01:01] <Kinnison> I couldn't spot it
[01:01] <Kinnison> :-(
[01:07] <stub> jamesh: So now that the GPG web-of-trust code is available on staging, what should I run to set it off?
[01:08] <carlos> do we have any testing account on production?
[01:14] <SteveA>     +   Module canonical.launchpad.database.bugtracker, line 68, in __getitem__
[01:14] <SteveA>     +     raise KeyError, id
[01:14] <SteveA>     + KeyError: <built-in function id>
[01:15] <SteveA>
[01:15] <SteveA> hahahaha
[01:18] <lifeless> did that do what I think it did ?!
[01:20] <SteveA> i imagine that someone changed the name 'id' to the name 'name' in that function
[01:20] <SteveA> but left it raising KeyError, id
[01:20] <SteveA> so id became the global builtin
[01:21] <lifeless> yah
[01:26] <stub> It could also mean someone passed __builtin__.id into the __getitem__ method
[01:27] <stub> id might be a valid local that happens to be bound to the __builtin__ ;)
[01:28] <SteveA> and furthermore
[01:29] <SteveA> a rogue C extention could be corrupting the heap and causing a legitimate string id to be replaced with that function
[01:31] <stub> Nah - it is a buggy __repr__ method on the id object
[01:31] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  sync (patch-9<EMAIL_ADDRESS>[01:31] <stub> def __repr__(self): return repr(id)
[01:38] <carlos> jordi, request sent
[01:42] <stub> carlos: any reason to keep the -v option on poimport?
[01:42] <carlos> stub, no, you can remove it now that we detected why it was not working
[01:52] <jordi> carlos: thansk mate
[01:53] <carlos> np
[01:58] <mpt> Gooooooooooooood morning
[01:58] <mpt> "Unable to fork for patch", eh
[01:58] <stub> The same file has been added on two branches, and I get two conflicts (the file, and the .arch-ids/thefile.id). How to I resolve it?
[02:00] <stub> lifeless, ddaa: ^^^
[02:01] <ddaa> baz resolved --all?
[02:01] <ddaa> I mean
[02:01] <ddaa> is that two files with different contents or same name
[02:01] <ddaa> or is that just the merge bug that cannot deal with redundant adds?
[02:02] <stub> baz resolved .arch-ids/uuid.py.id
[02:02] <stub> resolved: One or more of the paths supplied doesn't exist.
[02:02] <ddaa> baz resolved --all
[02:02] <ddaa> I know baz resolved is buggy with conflicting adds.
[02:02] <stub> ok. So leave it until I resolve everything else, and do the global resolve.
[02:03] <lifeless> stub: no
[02:03] <lifeless> stub: choose one of the fiells
[02:03] <lifeless> stub: and one of the ids
[02:03] <ddaa> well, you also need to remove one of the ids
[02:03] <lifeless> stub: move them into the the right place
[02:03] <lifeless> stub: delete the other two
[02:03] <ddaa> but that will appear in status anyway
[02:04] <ddaa> better again, try doing the merge without spurious conflicts
[02:04] <stub> lifeless: Did that. The .id still stays on the conflict list and I can't resolve it individually (I avoid --all incase I miss one)
[02:04] <lifeless> stub: ignore the conflict list
[02:04] <lifeless> stub: ;0
[02:05] <lifeless> ddaa: if its added twice it will always conflict, its not spurious
[02:05] <ddaa> I think you are wrong, for subtle reasons
[02:05] <lifeless> ddaa: you have the same file, with two different ids, but sharing the same path
[02:05] <ddaa> But I do not wish to have an argument about it at this current time and place
[02:05] <lifeless> ddaa: that is a conflict in any VCS I know
[02:06] <ddaa> oh sure, except there's a bug in merge where that happens for files with the same id
[02:06] <lifeless> ddaa: there is a separate bug, where if the file path is different, it doesn't know how to choose the right move target
[02:06] <lifeless> ddaa: but thats not what I understood to be the case here
[02:07] <ddaa> frankly I've given up trying to interpret most baz bug reports
[02:07] <ddaa> there are few stock solutions to ease the immediate pain
[02:08] <ddaa> but most of the time what the users say is so out of line with what the problem actually is that's it's not worth it
[02:08] <stub> It isn't a spurious conflict. I committed the same file on another branch because I needed the module and someone hadn't reviewed it yet. And now I'm cleaning up.
[02:08] <matsubara> good morning
[02:09] <lifeless> ddaa: well, fwiw, when I've looked at the 'why am I getting random conflicts' stuff, its always been history shortcuts
[02:09] <bob2> etoohardtofix
[02:09] <lifeless> which is a known issue in baz, and not relevant to bzr
[02:09] <lifeless> so I don't think we're getting stuff thats out of line, its quite predictable within the bounds of c-baz
[02:11] <SteveA> jamesh: great news aobut bug 1749
[02:12] <SteveA> (launchpad was offline when i wanted to look earlier)
[02:14] <ddaa> history shortcuts?
[02:19] <ddaa> lifeless: most of the time here, it turns out to be a criss-cross situation.
[02:19] <ddaa> Apparently pqm encourages a pattern that causes criss-cross:
[02:19] <ddaa> 1. send merge request
[02:20] <ddaa> 2. merge rocketfuel before starting working on something else
[02:20] <ddaa> 3. merge performed by pqm
[02:20] <lifeless> ddaa: criss-cross is ok with baz merge, as long as you are not cherry picking
[02:21] <lifeless> ddaa: not ideal either, but not bad, it will just take the common base before.
[02:21] <ddaa> except when baz merge goes out of memory trying to cache the whole history since the big bang
[02:21] <lifeless> ddaa: usually you get one too far back, and thats due to history shortcuts
[02:22] <ddaa> lifeless: let's abandon this line of discussion. I have no desire to rant about baz.
[02:22] <lifeless> ddaa: ok
[02:22] <lifeless> ddaa: note I'm not defending accuracy or reliability, just cause
[02:29] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  converted a bunch of browser:traverse into navigation (patch-2598<EMAIL_ADDRESS>[02:38] <lamont> lifeless: bazaar_1.4.2-1ubuntu1 has unaligned loads and/or stores in it's sha1 code.  fix that. kthxbye.
[02:39] <lamont> I suppose I should track down _where_, huh?
[02:40] <lifeless> bug reports - you know things with patches - are welcomeed
[02:40] <bob2> I think he stole the sha1 code from elsewhere
[02:41] <lifeless> blame colin walters
[02:50] <carlos> SteveA, I have a request for the sysadmin
[02:50] <carlos> should I add it to https://wiki.canonical.com/LaunchpadSysadminRequests ?
[02:51] <SteveA> carlos: you can mail it to RT
[02:51] <SteveA> i'll msg you the email address
[02:51] <carlos> ok
[02:51] <carlos> thanks
[02:51] <SteveA> it's a good idea to cc me or kiko
[02:51] <SteveA> or both
[02:51] <carlos> ok
[02:53] <ddaa> lifeless: in your "ignore annoying mac filenames in python" cscvs patch
[02:53] <ddaa> what does "note that hiding all should be ok - validation checks the final result." mean?
[02:54] <ddaa> lifeless: that's a clarification requested to me by spiv, since your patch ended up in one of my reviewed branches
[02:58] <lifeless> ddaa: it means that hiding all invalid file names is ok, as live ones will trigger a end-result validation failure
[02:58] <ddaa> okay
[02:58] <ddaa> thanks, it would be nice if you were a bit more proactive at getting your branch merged, though
[02:59] <ddaa> I'll handle that one.
[03:00] <lifeless> ddaa: that one I deliberately left for you
[03:01] <lifeless> ddaa: as you had other stuff you said to me you didn't want interrupted
[03:01] <lifeless> some time back
[03:01] <ddaa> ha... I guess so. It's hardly an extensive patch, I do not think it would have blocked me.
[03:02] <ddaa> is that the same issue with your pybaz patch? :)
[03:02] <ddaa> (I know it's not, I'm just teasing)
[03:03] <lifeless> no
[03:04] <lifeless> that one is me having to do a fix to hct
[03:04] <lifeless> and I keep getting halfway to doing it
[03:04] <lifeless> :/
[03:05] <ddaa> BTW, keep in mind that my next big chunk next week is working on the BranchDataStorage db patch.
[03:05] <ddaa> So large amounts of HCT borkage are to be expected.
[03:05] <bradb> kiko-zzz: Hey. Any news on the sortorder widget patch I sent you yesterday?
[03:05] <ddaa> lifeless: also, I'd like to know who is likely to work on cscvs/bzr and improtd/bzr?
[03:09] <stub> SteveA: BrowserNotificationMessages is now conflict free
[03:09] <SteveA> thanks
[03:09] <SteveA> i'm about to change that ;-)
[03:09] <SteveA> probably not actually
[03:09] <SteveA> but i'll review it after i send this next merge off, and get some lunch
[03:10] <SteveA> stub: i've converted all NotFoundErrors from zope to launchpad
[03:19] <kiko> hey ho
[03:28] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Added plural forms for Tagalog and associated Philippines's languages to that country (patch-2599<EMAIL_ADDRESS>[03:29] <bradb> hey kiko
[03:29] <bradb> kiko: might you have a chance to review the sortorder widget patch this morning?
[03:35] <kiko> bradb, yeah, but I need to spend some time with matsubara and gneuman first -- is it blocking you?
[03:35] <bradb> not really blocking me, no
[03:37] <kiko> carlos the bugspammer :)
[03:39] <SteveA> salgado: hi
[03:39] <salgado> hi SteveA
[03:39] <SteveA> so, in my merge that is with pqm, i commented out two shipit doctest lines
[03:39] <SteveA> because there's a query with ambiguous ordering
[03:40] <SteveA> i mailed you a link to a traceback
[03:40] <salgado> SteveA, I've been looking into that for the past 15 minutes
[03:40] <SteveA> okay
[03:40] <SteveA> i commented them out so that pqm wouldn't maybe fail
[03:41] <salgado> can't find what could be wrong, as the requests are always ordered by the date requested
[03:41] <SteveA> maybe there are two things with the same date
[03:41] <SteveA> are they ordered by id also?
[03:41] <salgado> no, they're not
[03:42] <salgado> I guess that would solve it
[03:42] <salgado> but first I want to make sure what's going on
[03:43] <SteveA> so, make the test return the name and the date
[03:43] <SteveA> then you'll be able to see
[03:44] <salgado> I just did that. and yes, there's three things with the same date
[03:45] <SteveA> great
[03:45] <SteveA> tvarka
[03:45] <SteveA> you might want to either wait for PQM to process my latest stuff
[03:45] <SteveA> or merge from<EMAIL_ADDRESS>[03:45] <SteveA> before you send that to pqm
[03:46] <salgado> I'll wait for pqm. how long since you sent your branch there?
[03:47] <SteveA> it will arrive 55 minutes in the future
[03:47] <SteveA> at Fri Oct 7 14:39:15 2005 UTC
[03:47] <salgado> 7 minutes. that probably means at least 30 more minutes to run all the tests
[03:47] <SteveA> lifeless: the times on http://pqm.ubuntu.com/ are 1 hour in the future
[03:47] <salgado> that should be enough time for me to poke kiko and get my shipit-searching branch reviewed
[03:47] <lifeless> SteveA: oh, are they GMT not UTC ?
[03:48] <salgado> kiko, that's an easy one. ;)
[03:48] <lifeless> SteveA: erm, BST I guess I mean
[03:48] <kiko> salgado, do you really want to land that today? I was thinking we should focus on getting any trivial fixes landed first
[03:48] <kiko> also
[03:48] <SteveA> lifeless: the page says UTC
[03:48] <kiko> I need your help on a frigging merge crapola that baz inflicted on me
[03:48] <lifeless> SteveA: yes, but what is it really ?
[03:48] <kiko> it nuked cronscripts/shipit-exports.py, salgado
[03:48] <kiko> can you believe it?
[03:48] <SteveA> but if you remove UTC and say BST then they will read right, at least today
[03:48] <SteveA> no idea about after DST changes
[03:48] <lifeless> SteveA: ok, so its getting localtime not UTC.
[03:49] <lifeless> SteveA: can you file a bug on pqm in launchpad for me ?
[03:49] <salgado> kiko, of course I can!
[03:49] <kiko> #@!#!$!@!!@*&
[03:50] <SteveA> lifeless: done
[03:50] <lifeless> SteveA: thanks
[03:51] <lifeless> SteveA: now I will ignore that for a year or so
[03:51] <SteveA> yeah, and one hour
[03:51] <lifeless> SteveA: and then when you complain next time dst comes around
[03:51] <lifeless> I'll be enthused and work on it
[03:51] <SteveA> i'll ask elmo to set the local time on that box to NZ
[03:51] <lifeless> ROTFL
[03:52] <jamesh> NZ time is a fair bit different to Sydney time
[03:52] <lifeless> jamesh: but so much more accurate
[03:52] <lifeless> :)
[03:52] <jamesh> lifeless: UTC+14:00?
[03:55] <lifeless> jamesh: +12
[03:55] <jamesh> lifeless: I met some kiwis pushing for 2 hours daylight saving when I went over there :)
[03:56] <lifeless> jamesh: city folk :P
[03:56] <jamesh> they wanted 1 hour DST in the winter and 2 hours in the summer
[04:00] <lifeless> night all
[04:07] <mpt> carlos: ping
[04:23] <carlos> kiko, ;-)
[04:23] <carlos> mpt, pong
[04:24] <mpt> carlos, let's talk about https://launchpad.net/products/rosetta/+bug/2036
[04:24] <kiko> it's the unbelievable sabdfl!
[04:24] <kiko> skin and bones!
[04:24] <carlos> mpt, ok
[04:24] <mpt> carlos: What templates are we currently showing, and why?
[04:25] <kiko> Ubugtu?
[04:25] <carlos> mpt, we are showing all templates that distribution has that have at least one translation
[04:25] <carlos> mpt, the idea is to show all of them
[04:25] <carlos> the fact that some are missing is a bug
[04:25] <mpt> How can they ever get from 0 translations to 1 translation?
[04:26] <carlos> mpt, because you reach them using another paths or a new .po file is imported
[04:26] <mpt> carlos: other paths such as what?
[04:27] <carlos> mpt, for instance /rosetta points to many of those translations
[04:27] <mpt> ok
[04:28] <mpt> carlos, why are you hiding the ones with 0 translations in the first place?
[04:28] <carlos> mpt, and as soon as gina is executed on production distros/ubuntu/breezy/+sources
[04:28] <carlos> mpt, as I said, it's a bug
[04:28] <carlos> well, I guess it's a bug
[04:28] <carlos> I doubt mark had any interest on hidding them
[04:29] <mpt> ok
[04:29] <mpt> so there's nothing really that I need to design here
[04:30] <mpt> carlos, one more question: I'm looking at https://launchpad.net/distros/ubuntu/hoary/+lang/hi
[04:30] <carlos> mpt, a good way to prevent that that page sucks so much
[04:30] <mpt> carlos: I can't work out what order the templates are listed in
[04:31] <carlos> mpt, no order at all
[04:31] <carlos> we need to add an orderBy to that query
[04:31] <mpt> ok, I'll report that bug
[04:31] <carlos> I doubt it has it
[04:31] <carlos> I think we have that one already
[04:34] <mpt> I don't see it
[04:34] <mpt> when searching for "order" or "sort"
[04:35] <mpt> there's bug 20, but that's not quite the same
[04:38] <carlos> ok, then file it, please
[04:42] <mpt> done, bug 2938
[04:47] <carlos> mpt, thanks
[04:57] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  lots of tidying up.  converting all database classes to use NotFoundError consistently, and to import it from launchpad.interfaces in preparation for the move to a new zope3.  Also, introduced a NameNotAvailable error.  removed browser:traverse rdirective.  commented out shipit test that fails sometimes. (patch-2600<EMAIL_ADDRESS>[05:04] <mpt> bradb: will your package nameage get into the next production update?
[05:05] <bradb> mpt: I think so, since I merged it before what I understand to be the cutoff date.
[05:08] <zorglub_> hello, I simply haven't found how to edit a bug's details (severity, ...)
[05:08] <bradb> I have to add back that link, this is just too silly. ;)
[05:08] <bradb> zorglub_: you have to click on the package name
[05:09] <zorglub_> ahah ok
[05:09] <mpt> bradb: or restore the underlining and the bug icons, like I wanted to do
[05:10] <bradb> mpt: that doesn't help much, IMHO
[05:10] <mpt> You haven't seen it
[05:10] <bradb> i can imagine it though
[05:11] <bradb> mpt: even with a neon sign saying "THIS IS CLICKABLE", it still gives basically no hint whatsoever that that's where you're supposed to go to edit the assignee/status details
[05:11] <bradb> particularly when seen through the eyes of someone who isn't that familiar with Malone
[05:12] <mpt> Sure, the controls should already be on the page you're looking at
[05:12] <salgado> than having to click on the package/upstream name
[05:12] <bradb> mpt: yeah, that would be even better. ;)
[05:12] <mpt> but any design that's repeating the same word over and over again is wrong
[05:12] <bradb> salgado: [Edit]  was shown to be invisible, in user testing
[05:13] <bradb> because [Edit]  still doesn't say "this is what you click to edit the assignee/status details"
[05:14] <salgado> indeed, but the package name doesn't do that either
[05:14] <bradb> salgado: correct :)
[05:15] <sabdfl> we should have a mini-icon that means "edit", and use it liberally.
[05:20] <mpt> sabdfl, we do have an edit mini-icon (/@@/edit.gif)
[05:20] <dilys> Merge to<EMAIL_ADDRESS>[r=spiv]  python high bit filename filtering (patch-113<EMAIL_ADDRESS><EMAIL_ADDRESS>[05:20] <mpt> I think the problem is that having to go to a separate page at all is so unnecessarily different from (and less efficient than) other bug trackers, that even that might not make it obvious
[05:21] <mpt> if "[Edit] " didn't work, I doubt an icon for the same would work.
[05:21] <sabdfl> mpt: until the edit form controls can be made tight enough to fit in the current task headline bar, we will retain a separate page, 'k?
[05:22] <mpt> sabdfl: sure, I'm not allowed to change the page at all, so need for more specific restrictions :-)
[05:23] <mpt> hooray, mirror finished
[05:27] <Kinnison> re
[05:39] <sivang> hey Kinnison
[05:40] <Kinnison> hi sivan
[05:42] <bradb> "The world will change this week" -- said by a passerby who saw my new bugtarget search portlet
[05:43] <bradb> salgado: Do you have time for a code review in the next hour or so?
[05:48] <salgado> bradb, how big is it?
[05:49] <bradb> salgado: I don't have the diff ready yet, but it's pretty small (it *looks* a lot bigger than it is, because of adding the new portlet in a bunch of different places, but the core code is probably 100 lines)
[05:50] <salgado> bradb, I can do it after lunch
[05:50] <salgado> in 1h, aprox.
[05:50] <bradb> salgado: awesome, thanks. i'll send it off in a bit.
[05:56] <mpt> heh
[05:56] <mpt> I thought I cleared the status notes, but left behind carlos's word "Cheers"
[05:58] <kiko> :)
[06:04] <sabdfl> bradb: ping
[06:04] <bradb> sabdfl: pong
[06:04] <sabdfl> just discovered your DistroSourcePackage work
[06:05] <sabdfl> i have a mostly-fledged DistributionSourcePackage
[06:05] <sabdfl> how much work did you do on DistroSourcePackage? which pages are there? url's?
[06:05] <sabdfl> i'll need to integrate our work
[06:06] <bradb> hm
[06:06] <bradb> there's the bug listing
[06:06] <bradb>  /distros/ubuntu/+sources/mozilla-firefox/+bugs
[06:06] <sabdfl> ddaa: niemeyer joins you on LP next week
[06:06] <SteveA> bradb: pqm will shortly be nuking browser/traversers.py
[06:07] <sabdfl> has all of that branch work landed?
[06:07] <sabdfl> SteveA: urgh
[06:07] <SteveA> why urgh?
[06:07] <sabdfl> does it all migrate to class files?
[06:07] <SteveA> yes.  all migrated already
[06:07] <SteveA> this is just rearranging things
[06:07] <SteveA> into the proper modules
[06:08] <SteveA> now, i'm in a position to solve the breadcrumbs problem
[06:08] <sabdfl> nice
[06:08] <sabdfl> with that, and a pillars-of-launchpad tweak or two, our page layout will start to become very usable
[06:09] <SteveA> traversers.py was the last hold-out of "everything from everywhere in one module" in the browser code
[06:09] <sabdfl> it's already a zillion times better than it was six months ago
[06:09] <bradb> sabdfl: basically other than the bug page, there's just little bits of infrastructure (like the *Set, the interfaces) and tests. nothing too serious.
[06:09] <SteveA> yeah.  i'm finding launchpad not too bad to use for bugtrackingn etc. now
[06:09] <bradb> i did the minimum required to make it work for me
[06:10] <sabdfl> bradb: is it done, i.e. you don't have more branches that are landing with changes to it?
[06:10] <bradb> sabdfl: I'm changing the dsp bug page a little bit now, to make it work with the bugtarget search portlet.
[06:12] <bradb> that should be landed within a few hours
[06:13] <bradb> sabdfl: I also added back the menu on another branch (seemed to have gotten blown away during the menus integration.) that patch is awaiting kiko's review.
[06:14] <mdke> jordi, ping
[06:20] <sabdfl> what's a dsp url with sampledata?
[06:21] <mdke> jordi, unping, i'll email
[06:22] <bradb> sabdfl: /distros/debian/+sources/mozilla-firefox/+bugs, IIRC
[06:23] <sabdfl> bradb: i do like the move to non-table listings...
[06:23] <bradb> It's nice when they aren't that many bugs being displayed, IMHO.
[06:27] <sabdfl> bradb: i'll tidy up the layout a little
[06:27] <sabdfl> drive-by polishing
[06:27] <bradb> sabdfl: Can you wait on that for just a bit? You might conflict with me and mpt
[06:27] <sabdfl> ok
[06:28] <bradb> thanks
[06:32] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Make sure reloads on the shipit-myrequest page won't blow up in user's face. (patch-2601<EMAIL_ADDRESS>[06:32] <kiko-fud> heh
[06:32] <kiko-fud> always nice to see somebody that cares for the end-user's good looks
[06:33] <kiko-fud> MIRROR BAZ MIRROR
[06:33] <sabdfl> bradb: conflicts ahoy on DistroSourcePackage...
[06:34] <bradb> sabdfl: Maybe it's due to the nav stuff.
[06:34] <sabdfl> bradb: no, i just have to merge to entirely different "distribution source package" implementations :-)
[06:34] <SteveA> that's touched mainly browser code
[06:35] <SteveA> although i have made the not found exception stuff better in database code
[06:35] <sabdfl> bradb: yours should not have been inside files called "packages.py" and "sourcepackage.py"
[06:35] <SteveA> carlos: ping
[06:35] <sabdfl> please observe the pattern
[06:35] <SteveA> aha!
[06:36] <sabdfl> it should have gone into browser/distrosourcepackage.py and database/distrosourcepackage.py
[06:36] <sabdfl> ok?
[06:36] <bradb> sabdfl: right
[06:36] <SteveA> i thought that was odd when i was adding browser navigation code for that
[06:37] <sabdfl> why do you need the __eq__ and __ne__ methods?
[06:38] <mdke> i have two wikinames
[06:38] <mdke> is it because I am special?
[06:38] <bradb> sabdfl: so that .target comparisons Just Work, regardless of what kind of object .target is.
[06:38] <sabdfl> ok
[06:38] <mdke> damn, everyone has two
[06:39] <sabdfl> bradb: remember we talked about the quality of the current release and the whole distro w.r.t. bugtasks?
[06:39] <sabdfl> i.e. closing a bug in breezy now would also close it in ubuntu?
[06:39] <sabdfl> is that implemented?
[06:39] <sabdfl> and in email interfaces?
[06:39] <bradb> sabdfl: not implemented yet
[06:39] <sabdfl> is there a spec?
[06:39] <bradb> no that i know of offhand
[06:40] <sabdfl> could you create a one-paragraph braindump, register in LP, and put on the UBZ agenda please?
[06:40] <bradb> sure, i'll do that now
[06:40] <sabdfl> thanks
[06:41] <SteveA> sabdfl: is that because breezy is the "current dev release" of ubuntu?
[06:42] <SteveA> or is that a special case?
[06:45] <sabdfl> SteveA: yes
[06:45] <sabdfl> sorry
[06:45] <sabdfl> current dev release fixing should also fix distro bugtask
[06:46] <SteveA> right, figures
[06:50] <zyga> is there any # for translators
[06:51] <sabdfl> bradb: ok, looks like we need to do a bugzilla import script...
[06:51] <bradb> indeed :)
[06:51] <sabdfl> we have about 2,900 open/new/pendingupload bugs on ubuntu
[06:51] <sabdfl> malone will easily handle that
[06:51] <bradb> yup
[06:53] <bradb> sabdfl: the spec i added for the task res. issue is here: https://wiki.launchpad.canonical.com/ResolvingTargetedBugTasks
[06:55] <carlos> SteveA, pong
[06:55] <SteveA> carlos: pitti sent an update about language packs
[06:55] <carlos> ok
[06:58] <carlos> bad news... need to investigate a bit, I think that perhaps a reimport should fix that...
[07:00] <SteveA> carlos: let me know what happens with it please
[07:00] <carlos> SteveA, sure
[07:07] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  nuke browser/traversers.py (patch-2602<EMAIL_ADDRESS>[07:10] <jordi> carlos: fantastic!
[07:10] <jordi> carlos: thanks for fixing; ie, loading me with a ton of work :P
[07:11] <carlos> ;-)
[07:15] <jordi> mdke: next time, for Rosetta issues, mail rosetta@ so Carlos will read too. This export thing seems something he'll be able to analyse correctly
[07:16] <bradb> salgado: patch sent!
[07:17] <jordi> carlos: the ubuntu-doc people are getting a pair of files that don't validate, with duplicate msgids
[07:17] <bradb> Kinnison: ping
[07:18] <bradb> Kinnison: From what header is the sourcepackage maintainer set?
[07:19] <Kinnison> pardon?
[07:19] <bradb> maybe i'm asking the wrong person
[07:19] <Kinnison> perhaps you're asking the wrong question
[07:19] <bradb> Kinnison: do you know how our maintainership data is populated?
[07:20] <Kinnison> no
[07:20] <bradb> hm
[07:20] <bradb> kiko-fud: do you know how our maintainership data is populated?
[07:22] <kiko-fud> via gina
[07:22] <Kinnison> bradb: What table are you on about?
[07:22] <bradb> Kinnison: maintainership
[07:23] <Kinnison> bradb: I thought that was a fairly manual process
[07:23] <bradb> kiko-fud: Mm, last I asked (though I don't recall who I asked), I was of the understanding that maintainership data comes from the uploads.
[07:23] <kiko-fud> bradb, we don't deal in uploads yet -- all our data comes from gina
[07:23] <bradb> I guess gina polls that data every so often?
[07:24] <kiko-fud> right
[07:24] <kiko-fud> it looks at the archive
[07:24] <bradb> kiko-fud: what piece of data does gina look at to get the maintainer?
[07:24] <kiko-fud> the releases file IIRC
[07:24] <bradb> Because I'm thinking: is this going to work for inherited packages?
[07:25] <Kinnison> I hate to say this, but gina doesn't touch the Maintainership table at all
[07:25] <kiko-fud> it should though :)
[07:25] <Kinnison> The archive can't tell us who maintains what
[07:25] <Kinnison> it doesn't always know
[07:25] <Kinnison> Plus in Ubuntu we don't always have a specific maintainer
[07:25] <Kinnison> (per-se)
[07:26] <bradb> so, this field will be manually overrideable, presumably?
[07:26] <bradb> i.e. in the web UI?
[07:27] <carlos> jordi, I'm aware of that
[07:27] <bradb> I have to give a clear answer to Kamion and mdz about how they can set the maintainer in cases where the data we've loaded is incorrect.
[07:27] <kiko-fud> Kinnison, at least in the old sourcpackage model we set the maintainer correctly
[07:27] <carlos> I think they filed a bug and I already answered them
[07:28] <carlos> jordi, I think it's related with obsolete messages
[07:28] <Kinnison> kiko-fud: setting the maintainer in the sourcepackagerelease is *NOT* the same as setting a maintainership record
[07:28] <Kinnison> sabdfl: can you chime in here please?
[07:28] <kiko-fud> Kinnison, it used to be, in the old sourcepackage model.
[07:29] <Kinnison> kiko-fud: it hasn't been for about 9 months
[07:29] <kiko-fud> it's not my fault you were born into the 90s
[07:30] <sabdfl> we don't have a "make me the default assignee for bugs on this" table
[07:30] <sabdfl> we have package subscriptions
[07:30] <sabdfl> which are "cc me on bugs on this package"
[07:30] <sabdfl> but it makes sense to add this
[07:32] <bradb> heh
[07:32] <kiko-fud> he hath spoken
[07:33] <bradb> That still leaves the original problem unresolved, it seems.
[07:33] <bradb> ISTM that the maintainer of the package must be set correctly, however that is done.
[07:33] <kiko> well
[07:33] <kiko> you first need to ask yourself
[07:33] <bradb> Inherited package or not, otherwise the user will be mislead and confused.
[07:33] <kiko> who is the maintainer of the package?
[07:34] <bradb> kiko: the person responsible for making sure the fix ends up in $distro
[07:34] <kiko> carlos, what do you think pitti's mail looks like
[07:34] <jordi> carlos: yes, it's not the first time obsolete msgs give us trouble
[07:34] <kiko> bradb, I'm not sure we know who that person is for all packages.
[07:34] <bradb> kiko: We probably don't. But shouldn't there be a way of letting the user manually enter that data?
[07:35] <kiko> for packages?
[07:35] <bradb> yeah
[07:35] <kiko> I guess -- it's not a very difficult change
[07:35] <kiko> but I'm not sure that's what maintainership is
[07:37] <carlos> jordi, I know, it's a know bug
[07:37] <jordi> carlos: got a bug number?
[07:37] <bradb> to me "default assignee" is a way of saying "i maintain this thing (even though it may be a non-forked package from an upstream distro)"
[07:38] <kiko> bradb, is that the same as maintainership? Kinnison?
[07:38] <bradb> it's a bit impure perhaps, but in the context of launchpad, i think it is.
[07:40] <bradb> i'm just guessing though. i don't have enough user input to do any more than that.
[07:41] <kiko> me neither. tell you what: is there anywhere in our code that currently uses that table?
[07:41] <bradb> yup, bugmail
[07:41] <kiko> anywhere else?
[07:41] <kiko> if not -- dude, go for it!
[07:41] <kiko> I'd rename it perhaps
[07:42] <bradb> go for it, i.e. make it editable?
[07:43] <kiko> use it to your advantage!
[07:43] <carlos> kiko, I think the problem is that we rejected many pofiles when we started with Rosetta and Hoary so it's a matter to review them by hand
[07:50] <carlos> jordi, https://launchpad.net/products/rosetta/+bug/2621
[07:50] <kiko> carlos, but dropped individual translations -- is that because the template is out of sync?
[07:51] <carlos> kiko, either the potemplate is out of sync or we missed some imports for Hoary
[07:51] <carlos> kiko, if breezy is not losing translations, hoary should not do that either
[07:51] <carlos> with breezy, every day we get new uploads
[07:51] <carlos> hoary is frozen already
[07:52] <carlos> so we need to force a new import to fix any issue we had
[07:58] <kiko> SteveA, will you STOP CONFLICTING WITH ME?!
[07:58] <kiko> it's the 4th time I request a merge!
[08:00] <kiko> carlos, I don't know if I understand exactly what you mean
[08:00] <kiko> oh
[08:01] <carlos> kiko, we did many fixes since the Hoary release
[08:01] <kiko> carlos, so we only include in the pofile translated strings -- no blanks?
[08:01] <carlos> so many .pot and .po files that were failing to import at that time will work now
[08:02] <carlos> kiko, ? I don't get your answer, sorry
[08:02] <kiko> it was a question :)
[08:02] <kiko> the pofile, it doesn't include blank translations, right? it only includes msgid/translation pairs for translation != ""?
[08:02] <kiko> the dropped plural form is weird
[08:02] <Kinnison> ciao
[08:05] <carlos> kiko, right, was a question, sorry
[08:06] <carlos> kiko, no, we have them too, but to compare the rosetta output martin removes them
[08:06] <carlos> kiko, about the dropped plural form, it's normal as long as we don't have any msgid_Plural
[08:07] <carlos> I need to debug it to be 100% sure that it's the case, but I have a test for that and I doubt it's incorrect (but all things are possible with real data...)
[08:08] <kiko> ah, I see.
[08:08] <kiko> yeah, you learned the language.
[08:10] <bradb> salgado: did you get my patch?
[08:11] <salgado> bradb, yep. reviewing it now
[08:11] <bradb> awesome
[08:12] <jordi> carlos: if mdke does an upload of a single po file and there are some strings that differ between the rosetta data and the po file he's uploading, what takes precedence, and what gets relegated to the translation memory?
[08:12] <mdke> i was thinking more of strings that are translated in rosetta, and not at all in the po file
[08:13] <jordi> oh, then rosetta should be smart.
[08:14] <carlos> jordi, if it's a published upload, Rosetta has preference if it's not a published upload, the .po has preference
[08:14] <jordi> carlos: good to know
[08:14] <jordi> carlos: and if the translations are missing in the upload, but are in rosetta, they get filled up, right?
[08:16] <carlos> jordi, they will be there, yes
[08:16] <carlos> or at least they should O:-)
[08:18] <jordi> hehe
[08:24] <kiko> salgado, ping?
[08:25] <salgado> kiko, pong
[08:25] <bradb> mpt: I'm attempting to look at your Malone front page changes now
[08:25] <kiko> salgado, you know person.activememberships and person.myactivememberships?
[08:26] <salgado> kiko, yes
[08:26] <kiko> well
[08:26] <kiko> the names kinda suck
[08:26] <kiko> I wanted to know
[08:26] <kiko> is it possible to add some asserts to them
[08:26] <kiko> to ensure you ran them on the right thing
[08:26] <kiko> for a person it doesn't even make sense to run activememberships, does it?
[08:27] <salgado> no, it doesnt. I even thought about merging them into a single method and act according to what self is
[08:27] <kiko> hmmm
[08:28] <kiko> tricky
[08:28] <kiko> because a team can have activememberships and myactivememberships
[08:28] <kiko> okay
[08:28] <kiko> I'll just add a note
[08:37] <kiko> ddaa, ping?
[08:44] <kiko> carlos, ping
[08:45] <bradb> mpt: hm
[08:45] <bradb> mpt: you completely blew away the portlets from the front page? :)
[08:45] <carlos> kiko, pong
[08:46] <bradb> mpt: This also assumes that global searching will work
[08:46] <kiko> carlos, https://launchpad.net/products/rosetta/+bug/1098
[08:46] <kiko> is it still relevant?
[08:49] <carlos> kiko, could be I didn't fix it, perhaps it was fixed as a side effect of another fix...
[08:49] <carlos> well, I wrote code before that bug that should prevent that error to happen, but seems like I did a mistake
[08:50] <kiko> it's an old bug
[08:50] <carlos> now that the language packs are more or less on their track I'm caring much more about bug reports so next week I will try to handle all big bugs and the permissions ones from Jordi
[08:50] <carlos> kiko, I know
[08:50] <kiko> okay
[08:50] <jordi> On the Translations page of a new project:
[08:50] <jordi> "If you would like to help translate Silva then you should ask the
[08:50] <jordi> Rosetta team to set it up by sending an email to the Rosetta mailing
[08:50] <jordi> list. You should give them the URL to the Silva.pot and .po files. You
[08:50] <jordi> will be able to start translating once they are imported."
[08:51] <jordi> carlos: can we change this to suggest that the URLs are a tar.gz with all the files?
[08:52] <bradb> Kinnison, kiko: do you know if our data model supports finding out if a package is 1. inherited (i'm guessing almost certainly yes) and 2. no different to the original package? can gina be made smart enough to make that distinction?
[08:52] <kiko> in theory yes
[08:52] <carlos> jordi, sure
[08:53] <carlos> jordi, file a bug and set me as the owner and set the urgency to high
[08:53] <jordi> carlos: thanks
[08:53] <jordi> k
[08:53] <bradb> kiko: hm. i wonder if there should be a distro default maintainer for inherited packages that aren't forked?
[08:53] <RWG> Carlos Marin
[08:54] <RWG> Crad Bollenback in Canada
[08:54] <RWG> *Bollenbach
[08:54] <RWG> *Brad
[08:56] <carlos> time to leave...
[08:56] <carlos> see you!
[08:56] <carlos> jordi, do you need anything from me
[08:56] <RWG> My fridge is rampaging in the next door neighbor's garden; I need to go cheer it on.
[08:57] <jordi> carlos: don't think so
[08:57] <jordi> carlos: have a nice weekend dude
[08:57] <jordi> carlos: only that I duoubt I can modify severity and owner
[08:59] <carlos> jordi, ok, don't worry
[08:59] <carlos> see you
[09:00] <jordi> https://launchpad.net/products/rosetta/+bug/2947
[09:00] <carlos> thanks
[09:03] <jordi> heh
[09:03] <jordi> I *rule* the karma top 5.
[09:06] <kiko> ddaaaaaaa
[09:06] <ddaa> that won't highlight my nick
[09:06] <kiko> two things
[09:06] <ddaa> I will have to leave in a few minutes
[09:07] <kiko> a) I did a baz replay --reverse and committed. is that okay? I ended up with an UNKNOWN patch in my history. Will PQM hate me?
[09:07] <kiko> b) Are you going to look into bug 2915?
[09:08] <ddaa> IIRC that tends to make log-for-merge unhappy, wich causes noise in rockefuel merge log
[09:08] <kiko> forever?
[09:08] <ddaa> you should do sync-tree after replay --reverse to restore the patchlog
[09:08] <kiko> darn
[09:08] <ddaa> until somebody fixes rocketfuel
[09:08] <kiko> is it too late for that now?
[09:08] <ddaa> I do not remember the specifics, it's not a critical problem anyway
[09:09] <kiko> can I go on working on the branch?
[09:09] <ddaa> kiko: 2915 is FIXED!
[09:09] <kiko> oh
[09:10] <ddaa> epiphany is removed from the GNOME project, epiphany-browser is now in the GNOME project
[09:10] <kiko> thanks
[09:10] <kiko> you're so sweet
[09:10] <ddaa> kiko: I think you should restore the patchlog for the reversed patch before sending a merge to rocketfuel
[09:11] <kiko> I will try
[09:11] <jordi> kiko: got a min?
[09:11] <kiko> jordi, sure
[09:11] <ddaa> but I might be confused, I remember there used to be a problem, but I'm not sure exactly what it was
[09:11] <bradb> kiko: how's it looking for that patch to get reviewed? it'll make your triaging life a lot easier. ;)
[09:11] <jordi> kiko: I've got a request to add a Shona team.
[09:12] <jordi> https://launchpad.net/people/shona
[09:12] <bradb> kiko: and it conflicts with the patch i sent to salgado, so i hoping to get them both sorted out and landed today
[09:12] <jordi> but this dude has messed up things it seems.
[09:12] <kiko> yeah
[09:12] <kiko> jordi, what is the issue?
[09:13] <jordi> should we rename this "shona" thing to ubuntu-l10n-shona, and when someone else joins, switch from shepard to this team for ubuntu translators?
[09:13] <jordi> kiko: we need to add shepard to ubuntu translators for the Shona language.
[09:13] <jordi> shona = sn
[09:13] <kiko> we can rename it now and update the ubuntu translators. are you ok with that?
[09:14] <kiko> jordi?
[09:14] <jordi> wrong, it's sna it seems
[09:14] <jordi> yes
[09:15] <kiko> so ubuntu-l10n-shona or -sna?
[09:15] <jordi> but, per sab policy, sheaprd should be enabled in ubuntu translators, not the team
[09:15] <jordi> not until there are more people in the team at least
[09:15] <jordi> or we can make an exception, now that the team is already created anyway
[09:15] <jordi> whatever you think is better
[09:15] <jordi> -sna
[09:16] <kiko> right
[09:16] <kiko> exceptions-r-us
[09:16] <kiko> oh-oh
[09:16] <jordi> no no no
[09:16] <kiko> it appears I can't rename it
[09:17] <kiko> salgado, how do I change a team's name?
[09:17] <jordi> they do have a two letter code "sn"
[09:17] <jordi> kiko: make it "sn"
[09:17] <kiko> ok
[09:17] <kiko> but I can't rename the team
[09:17] <kiko> so no luck yet
[09:17] <salgado> kiko, you can't. someone droped that
[09:17] <kiko> ah
[09:17] <kiko> that's what neuman's patch did
[09:17] <kiko> jordi, can you remind me to rename it next week?
[09:18] <jordi> kiko: yes. Should I mail you?
[09:18] <salgado> kiko, yes. I asked him to do that
[09:18] <kiko> next week, yes
[09:18] <jordi> mail you now, so you have it in your queue?
[09:18] <kiko> if you email me now, jordi, it will get lost
[09:18] <jordi> ok. let's see how I do to remember. :)
[09:18] <kiko> put an email in YOUR inbox :)
[09:19] <kiko> shephard appointed for ubuntu-sn
[09:19] <kiko> https://launchpad.net/rosetta/groups/ubuntu-translators/
[09:20] <kiko> ProgrammingError: ERROR: canceling query due to user request
[09:24] <jordi> shouldn't that be "cancelling"?
[09:24] <dilys> Merge to<EMAIL_ADDRESS>[r=spiv]  use svn_oo.util.pysvnClient instead of pysvn.Cleant, tweak inventory for bzr (patch-114<EMAIL_ADDRESS>[09:24] <jordi> kiko: many thanks
[09:25] <jordi> kiko: I have the same mail problem as you do I'm afraid
[09:25] <jordi> I'm slowly learning to flag CRITICAL stuff
[09:25] <jordi> critical = gets you fired if ignored :)
[09:26] <bradb> or "severity is meaningless", depending on who you talk to
[09:27] <bradb> in fact, we have a spec proposing to get rid of it
[09:36] <jbailey> bradb: Err. I trust that the spec talks about current use cases and what replaces them? =)
[09:36] <kiko> are there valid use cases for severity?
[09:37] <bradb> kiko: dude, my patch!
[09:37] <bradb> jbailey: not in detail, but in summary
[09:38] <jbailey> kiko: I use severity to know which bugs I need to fix before I go home, (critical), and which bugs I need to fix before release (major).  Trivial is cosmetic bugs that I can do when I don't feel like working and enhancements are things that probably need specs to go along with them.
[09:38] <jbailey> kiko: Everything else is normal.
[09:38] <bradb> jbailey: What do you use priority for?
[09:38] <kiko> jbailey, that sounds like priority tome.
[09:38] <jbailey> bradb: I don't. =)
[09:38] <kiko> jbailey, then you're misusing priority to represent severity
[09:38] <kiko> severity is something else.
[09:39] <kiko> errr
[09:39] <kiko> the opposite of what I said three sentences above.
[09:39] <bradb> jbailey: It sounds like you're using the thing that describes what effect the bug has on the user to prioritize fixing it
[09:39] <jbailey> Priority tells me which ones I would need to do first.
[09:39] <jbailey> I should probably prioritize the normal bugs.
[09:39] <kiko> no
[09:39] <kiko> well
[09:39] <kiko> not exactly :)
[09:39] <kiko> severity is how severe the bug is
[09:39] <jbailey> I'd rather give priority to my boss to tell me what order he'd like things done in.
[09:40] <kiko> if it's a showstopper, critical, world-crashing issue
[09:40] <kiko> severity doesn't really make sense for features and enhancements
[09:40] <kiko> priority indicates what order you should fix them
[09:41] <kiko> and you're right, priority is something that's more of a management thing
[09:42] <jbailey> I'd love mdz or people dealing with community etc to let me know which bugs people care about more.  In bugzilla land, it could even be through the vote system.
[09:43] <jbailey> Ultimately I need to know what *must* be done today.  Then I need to know what I ought to do tomorrow when this is out of the way.
[09:44] <jbailey> Basically, there will always be more bugs than time, so I think that's really what I'm looking for.
[09:44] <bradb> jbailey: we'll give you that
[09:45] <kiko> jbailey, what must be done today is P1
[09:45] <kiko> then you can order the rest using P2-P5
[09:45] <kiko> or alternatively
[09:45] <kiko> your manager can order it
[09:46] <jbailey> Right.
[09:46] <jbailey> The complication is...
[09:46] <jbailey> Some tasks are trivial and easy to get out of the way.
[09:46] <jbailey> So should be a higher priority so that we still take care of the little details.
[09:47] <kiko> right
[09:47] <kiko> so smaller, cheaper tasks should get higher priority
[09:47] <kiko> it's a traditional scheduling problem :)
[09:48] <jbailey> Yup =)
[09:48] <jbailey> And I hate to say it, but it would be nice if bugs from people with higher karma got a boost. =)
[09:50] <bradb> That would make Rosetta users happy.
[09:51] <bradb> Karma: 2938282
[09:53] <kiko> who's that?
[09:54] <bradb> noone, but rosetta's karma system is wacked ;)
[09:58] <jordi> bradb: could be me ;)
[09:59] <jordi> current karma is nearly 20k
[09:59] <bradb> heh
[09:59] <jordi> heheheheheh bradb has 813. :)
[09:59] <bradb> that's pound sterling
[10:04] <mdz> kiko,jbailey: things come in as P2; I bump them up to P1 if they're particularly important
[10:04] <mdz> jbailey: currently, what's important is the 5.10 milestone report I posted to -devel
[10:11] <Seveas> bug 1000
[10:11] <Ubugtu> Malone bug #1000: There are too many bug reports in Malone Fix req. for: upstream launchpad, Severity: Normal, Assigned to: Nobody, Status: Rejected http://launchpad.net/malone/bugs/1000
[10:11] <Seveas> mpt, see it works :)
[10:12] <mpt> great, thanks Seveas
[10:12] <Seveas> yw
[10:13] <mdke> nice one
[10:13] <bradb> cool
[10:14] <kiko> Seveas!
[10:15] <Seveas> kiko?
[10:15] <kiko> that rocks
[10:16] <Seveas> it knows the ubuntu and gnome bugzillae too if neccessery, justreplace 'bug' with gnome or ubuntu
[10:16] <jordi> kiko: where does rosetta get the name for a language?
[10:16] <Seveas> bugzilla/malone urls are triggers too
[10:16] <jordi> Asturian is incorrectly called "Asturian; Bable", when it should be "Asturian".
[10:16] <kiko> hmmm
[10:16] <kiko> jordi, I think that requires a database patch, file a bug
[10:18] <jordi> kiko: done.
[10:18] <jordi> spoke too fast
[10:18] <jordi> PRogrammingError
[10:19] <jordi> https://launchpad.net/errors/showEntry.html?id=1128716317.920.888504782347
[10:20] <jordi> I don't know if its related
[10:21] <jordi> but I changed the title from
[10:21] <jordi> Incorrect language name for "ast": "Asturian; Bable"
[10:21] <kiko> jordi, request expired right?
[10:21] <kiko> what's the bug #?
[10:21] <jordi> I don't know
[10:21] <jordi> now it got filed as 2951
[10:21] <jordi> after changing the title from "Incorrect language name for "ast": "Asturian; Bable"
[10:21] <jordi> fuck
[10:21] <jordi> damn
[10:21] <jordi> Incorrect language name for "ast": Asturian; Bable
[10:22] <jordi> to
[10:22] <jordi> "Incorrect language name for "ast": "Asturian; Bable"
[10:22] <jordi> ie, added quotes.
[10:22] <kiko> matsubara, I'm still waiting for your test -- am I going to get it today?
[10:22] <jordi> kiko: it didn't take long to show that error
[10:22] <jordi> a few seconds
[10:22] <kiko> yeah, it's weird
[10:23] <jordi> are you ok with what you have, or should I file a bug?
[10:34] <salgado> bradb, review sent. sorry for the delay
[10:36] <kiko> it's okay
[10:36] <kiko> a timeout, I think, jordi
[10:36] <bradb> salgado: cool, thanks
[10:40] <jordi> kiko: good
[10:40] <jordi> dinner time. Have a nice weekend folks.
[10:44] <jbailey> mdz: Ah cool, I didn't know that you used the Priority flags.  I hadn't been using them, so I uncluttered my display.
[11:16] <bradb> salgado: I've got a reply coming up in about 5 mins...
[11:16] <bradb> (with view tests, etc.)
[11:17] <kiko> bradb, sent too
[11:18] <bradb> kiko: thanks
[11:18] <bradb> i won't get to that one until monday...conflicts, etc.
[11:23] <bradb> salgado: reply sent
[11:26] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  mention gettext in About Rosetta page (bug 712) (patch-2603<EMAIL_ADDRESS>[11:27] <Ubugtu> Malone bug #712: Rosetta doesn't mention gettext Fix req. for: upstream rosetta, Severity: Normal, Assigned to: Matthew Paul Thomas, Status: New http://launchpad.net/malone/bugs/712
[11:30] <mpt> dilys, meet Ubugtu. Ubugtu, dilys. I'm sure you'll be very happy together.
[11:34] <salgado> bradb, back to Mac OSX?
[11:34] <bradb> running tiger on this machine, but ssh'ing into my other powerbook to do lp work
[11:36] <salgado> I noticed when got this html email
[11:36] <bradb> wha?
[11:36] <bradb> shit
[11:37] <bradb> changed
[11:37] <bradb> that's an embarassing default. i'm suitably humiliated.
[11:39] <salgado> bradb, I had the feeling the only way to test that would be with something like ClientForm, but asked just to make sure
[11:39] <bradb> ok
[11:39] <salgado> anyway, the tests looks fine
[11:40] <bradb> should i doit?
[11:40] <salgado> you mean, the merge? sure!
[11:40] <bradb> thanks
[11:47] <ddaa> cprov: you want the technical answer, or the real answer?