[12:04] <bradb> I don't think a normal human being would differentiate U/C/A. But U/C/IP could be worthwhile
[12:04] <mpt> yeah
[12:05] <mpt> whichever is done, it's wrong for someone else to be able to mark a bug as Accepted when it's assigned to me
[12:05] <mpt> because I might think the bug is complete crack
[12:05] <mpt> or something I don't know how to fix
[12:06] <bradb> yeah. LP doesn't really have workflows, ATM. at least not enforced programatically
[12:08] <mpt> LarstiQ, well, you and I understand it, but many don't, apparently including one or two of my managers :-)
[12:09] <mpt> bradb, would you be happy with "Being Fixed" instead of "In Progress"? (In Progress is possibly a little too similar to PendingUpload)
[12:09] <bradb> Being Fixed is even better
[12:09] <mpt> ok, cool
[12:16] <mpt> In other news, bradb, we seem to be getting a mountain of duplicate bug reports
[12:17] <mpt> from which I conclude that priority #2 is making searching work better :-)
[12:22] <bradb> our search is not very useful, sadly, but I don't think it's been a priority yet for stub to look into ispell integration and such. We're working on it though. For example, we added sourcepackage name to the bug searching during UBZ, but it doesn't appear to have been rolled out yet.
[12:25] <bradb> but yes, i'd fully agree on it being priority #2.
[12:25] <mpt> 'night
[04:49] <mpt> jordi, you may want to subscribe to bug 3954
[04:49] <Ubugtu`> Malone bug #3954: Tamazigh needs adding to Rosetta Fix req. for: rosetta (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/3954
[08:44] <SteveA> good morning!
[08:47] <jblack> HI!
[09:54] <SteveA> ddaa: good morning
[09:55] <ddaa> Hello SteveA
[10:14] <carlos> morning
[10:15] <SteveA> hi carlos
[10:16] <SteveA> oh, carlos, i had a question for you
[10:17] <carlos> SteveA, tell me
[10:20] <SteveA> carlos: okay, i have just forwarded you a mail that was on the schooltool mailing list, but also kind of a debian debbugs mail
[10:20] <carlos> ok
[10:20] <SteveA> there is a complaint about rosetta there which i think has been addressed
[10:21] <SteveA> so, i want to check what a proper reply to that is, and then to make the reply, so that the record is set straight
[10:24] <carlos> SteveA, ok, it was a side effect of our old codebase when we showed all those fr_FR, es_ES, etc... locales by default
[10:25] <carlos> Mark said that we should not expend time implementing a way to merge .po files
[10:25] <carlos> so the old ones remain there
[10:26] <carlos> but it's not easy to create new ones
[10:27] <SteveA> to create new translations in fr_FR you mean?
[10:27] <carlos> right
[10:28] <SteveA> okay.  so, what should the schooltool people do given the current situation?
[10:28] <carlos> ask for a merge of the fr_FR into fr by a French translator
[10:29] <carlos> downloading the .po file and uploading the merged one into the fr locale
[10:29] <carlos> and then ping me so I ask stub to remove that POFile from the database
[10:29] <carlos> it's the only way to fix it
[10:29] <SteveA> hmm... i can't describe that so well in an email.  so, i'll ask them to come here and talk with you about it.
[10:29] <carlos> of course, they should remove the fr_FR.po from the release
[10:29] <carlos> or Rosetta will add it again
[10:30] <carlos> SteveA, ok
[10:36] <SteveA> https://chinstrap.ubuntu.com/~dsilvers/paste/fileiifGVM.html
[10:36] <SteveA> carlos: does that read correctly?
[10:38] <carlos> SteveA, "so translators are not offered these language variants..." I think it implies that there is no way to create them anymore
[10:38] <carlos> and that's not true, if someone wants to do that, it's still possible
[10:38] <SteveA> ok
[10:39] <carlos> but you are not "invited" to do it, you should request it being explicit (uploading a fr_FR.po file or typing the URL by hand)
[10:39] <SteveA> okay
[10:41] <ddaa> SteveA: what is the recommended format for epydoc entries in launchpad docstrings? ReST or epydoc syntax? (or something else?)
[10:44] <SteveA> ddaa: i have no specific recommendation, because i don't use that style.  i can look into it and form an opinion if this is blocking you.
[10:44] <SteveA> carlos: sent the mail.
[10:44] <ddaa> I use ReST format generally, as it's the more likely to become "standard" in the future.
[10:44] <carlos> SteveA, ok, thanks
[10:45] <SteveA> jinty: hi.  you just missed carlos and me talking about how the schooltool po files / country-specific-language-variant translations can be fixed up in rosetta
[10:47] <SteveA> ddaa: can you get me URLs with examples of each of the alternatives?
[10:47] <SteveA> or examples in Kinnison's pastebin?
[10:51] <ddaa> SteveA: http://epydoc.sourceforge.net/fields.html
[11:05] <carlos> stub, hi, could you give me a patch number for the DB patch you reviewed yesterday? (The TranslationUploads branch)
[11:06] <stub> eh? oh. patch-40-04-0.sql
[11:06] <carlos> stub, thanks
[11:09] <SteveA> ddaa: i like this best: http://epydoc.sourceforge.net/fields.html#rst
[11:10] <ddaa> I do not like it because it does not allow putting types and descriptions side by side.
[11:11] <ddaa> When  i want to put types and descriptions or params I usually write:
[11:11] <SteveA> ddaa: what do you prefer?
[11:11] <ddaa> :param foo: The foo to froboize.
[11:12] <ddaa> :type foo: `IFoo`
[11:12] <ddaa> :param bar: The bar to have beer at.
[11:12] <ddaa> :return: Froboized foo with a pint.
[11:13] <ddaa> It's reasonably efficient in vertical space.
[11:14] <SteveA> hmm...
[11:14] <SteveA> why is it so important to have a separate :type: line for arguments, but not for the return value?
[11:14] <ddaa> There's :rtype: as well
[11:15] <ddaa> it's just that sometimes I give only a description, and sometimes only a type, sometimes both, sometimes none.
[11:16] <SteveA> okay.
[11:17] <SteveA> so, i can say this: if you want to use a structured docstring, use one of the rst formats, and not the javadoc or epytext format
[11:17] <ddaa> perfectly happy with that.
[11:37] <carlos> is there anyway to execute just one pagetest that uses librarian? ./test.py --test=... does not work
[11:41] <ddaa> I suggest "./test.py -v . name_of_the_test"
[11:41] <ddaa> the little dot in the middle is important
[11:42] <ddaa> where name is the filename for a doctest/pagetest or the method name for a unitttest
[11:48] <carlos> ddaa, will that execute librarian?
[11:48] <ddaa> mh...
[11:48] <ddaa> nah, don't think so... would have to start it by hand...
[11:49] <carlos> ok
[12:10] <matsubara> good morning!
[12:19] <cprov> good morning hackers
[12:20] <Nafallo> morning :-)
[12:21] <niemeyer> Morning Celso
[12:22] <niemeyer> cprov: I'd like to setup the build system here as we discussed at UBZ.. would you be able to talk about it today?
[12:22] <cprov> niemeyer: hi niemeyer, sure ... join ##soyuz 
[12:25] <cprov> niemeyer: I mean, when you have time.
[12:25] <niemeyer> cprov: I'm there :)
[12:25] <niemeyer> Alone.. :(
[12:25] <niemeyer> ;)
[12:26] <cprov> niemeyer: he, it wasn't a typo, double hash .
[12:26] <niemeyer> cprov: I'm there, really
[12:28] <cprov> niemeyer: sorry, ##soyuz1.0, which is totally out of context, whatever 
[12:29] <niemeyer> np :)
[01:16] <ddaa> Hey niemeyer
[01:18] <niemeyer> Hiho
[01:18] <niemeyer> What's up?
[01:18] <niemeyer> :)
[01:22] <ddaa> niemeyer: I've done lifeless' part of the review comments
[01:23] <ddaa> I've delayed doing yours until you could tell me whether I can expect it from you today.
[01:27] <niemeyer> ddaa: Yes, you may expect it for today
[01:27] <niemeyer> ddaa: What's the lifeless part that you've done?
[01:28] <ddaa> The "Robert blamed" bit. See new message in the launchpad-reviews mailing list.
[02:21] <Kinnison> SteveA: sorry, I felt so bad this morning I slept in 'til now
[02:21] <Kinnison> SteveA: I still have a sore throat but at least my head isn't spinning
[02:21] <SteveA> hello Kinnison 
[02:29] <LarstiQ> Kinnison: too much whooping yesterday?
[02:31] <Kinnison> LarstiQ: not quite :-)
[02:32] <SteveA> launchpad developers: make sure you're subscribed to https://wiki.launchpad.canonical.com/LaunchpadHackingFAQ
[02:45] <SteveA> ddaa: i added a note about docstrings to https://wiki.launchpad.canonical.com/LaunchpadHackingFAQ
[02:46] <ddaa> Thanks.
[02:58] <niemeyer> ddaa: Have you changed your branch (.../launchpad/branches) in any strange way?
[02:58] <ddaa> not that I'm aware of
[02:59] <niemeyer> ddaa: I did a pull and bzr removed *everything*
[02:59] <ddaa> mh
[02:59] <ddaa> You mean /home/warthogs/archives/david/launchpad/branches right?
[03:00] <niemeyer> Yes
[03:01] <niemeyer> bzr status shows a remove list with the whole launchpad.. :)
[03:01] <niemeyer> I'm updating bzr, and will try again
[03:02] <niemeyer> If it doesn't work, I'll have to resync everything.
[03:03] <ddaa> It looks sane on chinstrap, waiting for bzr status there
[03:03] <mhz> ji ther
[03:03] <mhz> hi
[03:04] <mhz> there
[03:04] <mhz> :)
[03:04] <niemeyer> ddaa: Yes, it looks fine indeed
[03:04] <niemeyer> ddaa: Which is even worse.. :(
[03:04] <mhz> Any chances LaunchPad assigns Karma for IRC and Wiki contributions?
[03:04] <mhz> and also for Talks and Evangelisation?
[03:47] <carlos> mhz, how would we track that?
[03:48] <mhz> carlos: no idea yet.
[03:48] <mhz> :)
[03:48] <carlos> mhz, the only way to track those contributions is manually....
[03:48] <mhz> maybe manually
[03:48] <mhz> hehehe
[03:49] <mhz> indeed
[03:49] <mhz> carlos: hablas castellano?
[03:49] <carlos> mhz, si
[03:49] <mhz> que bueno!
[03:49] <mhz> where are u from?
[03:49] <carlos> mhz, Spain
[03:50] <carlos> and you?
[03:51] <mhz> Spain is probably THE largest spanish speakers voice for free as in freedom community 
[03:51] <mhz> Chile
[03:52] <carlos> and the number country with the highest number of Debian based distributions in the world.... :-(
[03:53] <carlos> s/number country/country/
[03:54] <mhz> why sad?
[03:58] <carlos> mhz, we should not create that amount of distributions but contribute each other to improve a common base. At least now seems like some of them are moving to use Ubuntu as their base without forking it
[03:59] <mhz> carlos: really? to ubuntu? cool
[03:59] <mhz> I have been so much into the project that I loose outside perception
[03:59] <mhz> :)
[03:59] <mhz> AFAIK, ubuntu is a good base
[04:00] <mhz> so is Knoppix :D
[04:00] <mhz> morphix was close
[04:01] <mhz> IMHO, Ubuntu will become what RedHat meant to be (rpm's though) and Debian couldn't (not a company)
[04:04] <mhz> carlos: re-Karma/ so? how can it be manually?
[04:05] <carlos> mhz, no atm
[04:05] <carlos> mhz, we would need to figure a way to do it
[04:06] <mhz> carlos: do you understand why I ask?
[04:06] <carlos> mhz, please, file a bug against launchpad with that suggestion
[04:06] <mhz> ok
[04:07] <carlos> mhz, yeah, I understand your concerns as the karma is being used as a way to know your Ubuntu contributions
[04:07] <mhz> carlos: is there a 'why we use karma' doc or definition?
[04:07] <mhz> maybe karma is meant for 'developers' (code stuff)
[04:07] <carlos> mhz, we have a document that describes a bit how it's implemented
[04:07] <mhz> ok
[04:07] <mhz> thx
[04:08] <carlos> mhz, you get it translating or working with bug reports
[04:08] <carlos> so it's not a developer 'thing'
[04:08] <carlos> everyone can get it
[04:08] <mhz> ok, cool then
[04:08] <mhz> deserves a bug
[04:08] <mhz> deserves a bug filing
[04:12] <carlos> mhz, thanks
[04:12] <mhz> np
[04:12] <mhz> thank you all for LP
[04:12] <mhz> LP + Moin would rock!
[04:14] <JaneW> mhz: you always manage to get a punt in for moin :P
[04:14] <mhz> hehehehe
[04:15] <mhz> that's the idea
[04:15] <mhz> yesterday I was ina 3 hour meeting and I must have mentioned edubuntu at least 30 times
[04:16] <mhz> JaneW: the thing is that I tried trac once (very cool wiki + devel tools) and I noticed Moin was cooler. So now I see LP + Moin like a pretty cool idea
[04:16] <mhz> JaneW: hehehe
[04:32] <ddaa> This bzr transition puts me in a funny situation wrt to pybaz...
[04:32] <SteveA> ddaa: have many users been in contact about it?
[04:33] <ddaa> hard to tell... I have the impression that only a few intrepid devels ever used it, most of them are now on bzr...
[04:33] <ddaa> but I was sometimes surprised
[04:34] <SteveA> i know... put a release out there with obvious errors in the packaging, and see how many complain ;-)
[04:34] <LarstiQ> that works :)
[04:34] <ddaa> I have not put a release out in ages
[04:34] <LarstiQ> mhz_cooking: the wiki in trac is Moin based
[04:34] <ddaa> my release management sucks too much for that, people just get it from the baz archive
[04:35] <LarstiQ> cripple the baz archive? ;)
[04:35] <ddaa> I'll just do something horribly crippled and wrong for mirroring, so I get proper verbosity. Instead of added the right feature to pybaz.
[04:35] <SteveA> convert the baz archive of pybaz to bzr...
[04:35] <ddaa> * instead of adding
[04:36] <ddaa> SteveA: that sort of defeats the point of pybaz...
[04:36] <ddaa> well... I guess that would be a way of putting out a statement as well...
[04:37] <SteveA> maybe throw an email at mpool and lifeless and see what they suggest
[04:37] <ddaa> would be faster for me just to code the feature I need... on a bzr hosted branch.
[04:37] <ddaa> If anybody appear to care about pybaz in the future, I'll think about backporting.
[04:37] <ddaa> Thanks for talking. That helped me take a decision.
[05:27] <mhz> LarstiQ: yup, indeed
[05:27] <mhz> hence I say Moin+LP is cooler
[05:28] <mhz> .oO(my non english-thinking plays tricks on me, usually)
[05:29] <ddaa> SteveA: please review sftp://chinstrap/home/warthogs/archives/david/pybaz/iter_mirror ASAP
[05:29] <SteveA> ddaa: is it on the pending reviews page?
[05:29] <ddaa> just added :)
[05:52] <LarstiQ> mhz: I do miss some trac features in lp atm
[05:52] <mhz> which ones?
[05:53] <ddaa> LarstiQ: if you say "subversion integration" I'll go nasy ;)
[05:54] <mhz> nasy?
[05:54] <Nafallo> lol
[05:54] <ddaa> hu... "nasty"
[05:54] <mhz> oh, ok
[05:54] <LarstiQ> ddaa: no, afaics the timeline and source view
[05:54] <ddaa> mh... tell me more about the source view
[05:55] <ddaa> that might be part of the stuff I'm responsible for.
[05:57] <LarstiQ> ddaa: http://wiki.powerdns.com/projects/trac/browser/trunk/pdns/
[05:57] <ddaa> do you use the changeset view much?
[05:59] <ddaa> got to say that trac viewsource is quite nice, compared to the usual viewsvn nonsense
[06:00] <LarstiQ> ddaa: frequently enough, yes
[06:00] <ddaa> Would be a great feature to have in launchpad for bzr branches.
[06:00] <ddaa> (AND rcs imports!)
[06:00] <ddaa> look like a lot of work though.
[06:01] <LarstiQ> the timeline bit might already be solved
[06:01] <ddaa> What's the timeline thing?
[06:02] <LarstiQ> looks like the Moin recentchanges, for wiki edits/bug changes/changesets
[06:02] <LarstiQ> http://wiki.powerdns.com/projects/trac/timeline
[06:02] <LarstiQ> and it has an rss feed ;)
[06:02] <ddaa> mhhh
[06:02] <LarstiQ> malone has this for bugs via mail at least
[06:02] <LarstiQ> so it's mostly an integration question?
[06:03] <ddaa> not sure how that would work with a few dozen random community branches registered for a product... you'd probably not want community branches in the timeline.
[06:03] <ddaa> Maybe only branches associated to a series.
[06:03] <mhz> LarstiQ: http://projects.edgewall.com/trac/wiki/TracOnUbuntu
[06:03] <mhz> had you seen it?
[06:04] <ddaa> Wel... except for the linking to the viewsource, it looks like it would be reasonably easy to implement.
[06:04] <ddaa> well... once the branch migration to bzr is done, that is...
[06:04] <LarstiQ> ddaa: I'm mainly looking at it from my project point of view, our own trac is now nicer than lp
[06:05] <ddaa> Of course.
[06:05] <LarstiQ> mhz: that doesn't look that special?
[06:05] <LarstiQ> mhz: trac+bzr is more interesting for me :)
[06:06] <mhz> i know it is not special. it's good they are taking care of it (packaging it)
[06:06] <mhz> I know moin is packaged but not trac
[06:06] <ddaa> LarstiQ: It's not clear who should take time from other objectives to implement that feature. It will probably not be implemented unless your file a bug and talk sabdfl into it. Should not be difficult though.
[06:06] <LarstiQ> trac has been packaged for a loooong time
[06:07] <mhz> trac+bzr? excellent. I have heard a lot about bzr but nevere tasted it yet, only sbv.
[06:07] <ddaa> For bzr integration, it's going to take some time, if only because bzr integration is quite embryonic and I have a larg data migration (from baz) task in my pipe.
[06:07] <mhz> subversion, I meant
[06:08] <ddaa> That would be quite a shiny feature to have.
[06:15] <bradb> BjornT_: replied to X-Malone-Bug review
[07:35] <niemeyer> ddaa: Ouch.. you've sent bzrsync.py to the revision "as-is"..
[07:36] <niemeyer> ddaa: Including a print in the constructor. 8)
[07:37] <slomo> hi... is it possible to get the po files from rosetta with name and email adress and copyright of the author filled in?
[08:03] <ddaa> well, as far as your code works, I'm happy with it, it's the reviewer job to be picky about things like that ;)
[08:04] <bradb> BjornT_: ping
[08:05] <niemeyer> ddaa: Considering that you introduced the prints in the first place, I'm not surprised that you're happy with it. :)
[08:05] <niemeyer> ddaa: But using print inside a constructor is.. erm.. awful. :)
[08:06] <ddaa> Sounds a bit sloppy indeed.
[08:49] <niemeyer> SteveA: I'm not subscribed to launchpad-reviews, and the subscription seems to be moderated. Would you be able to approve it, please?
[08:53] <mpt> Does anyone know when the import of Ubuntu packages into Launchpad is happening?
[08:58] <bradb> BjornT_: ping
[08:58] <cprov> mpt: not really, it depends of the gina results in staging ... lot of timeouts atm.
[09:00] <SteveA> niemeyer: sure
[09:03] <SteveA> niemeyer: nope, i can't.  i think kiko is the manager of that list
[09:04] <niemeyer> SteveA: Ok, thanks for trying it
[09:05] <ddaa> jblack: ping
[09:06] <SteveA> ddaa: reviewing the pybaz code now
[09:08] <jblack> pong
[09:09] <ddaa> jblack: I've been reading CreatingBranchesOnSupermirror
[09:09] <ddaa> the spec says that autocreated branches should not be displayed in launchpad until title and description have been set.
[09:09] <ddaa> is that still what is intended?
[09:13] <niemeyer> ddaa: That was not the idea when we talked about it in UBZ
[09:14] <ddaa> niemeyer: that's why I'm asking, there's apparently a discrepancy.
[09:14] <jblack> ddaa: Publically displayed, you mean? 
[09:14] <ddaa> yes
[09:14] <niemeyer> :)
[09:15] <jblack> I think that there should be two options. A user level option to set a default, for which the default is to hide new branches.
[09:15] <jblack> That way, the branches list for someone doesn't get spammed up with throwaway branches.
[09:16] <ddaa> Mh... I see the motivation...
[09:16] <jblack> The question comes down whether the saner default is marking stuff thats good to talk about, or marking stuff that's not.
[09:17] <jblack> I expect that with the way that its trivial and encouraged to branch early and often, there will be a lot more stuff that's not pertinant enough to list.
[09:17] <jblack> Also, it prevents a problem with people pushing 30 branches and having a list of 30 things that say "undescribed branch in the some_branch" dir.
[09:18] <ddaa> My gut feeling is to rather display everything up front and then think about way to automatically show what is still relevent...
[09:18] <ddaa> jblack: that's not how I would make them appear.
[09:19] <jblack> We may be desynced. I'm thinking about pushsftp branches. are you thinking about import branches? 
[09:19] <ddaa> I'm just thinking that non-described branches could be listed, but less prominently (smaller font), with no rude nagging text and an obvious link to edit the description.
[09:19] <ddaa> jblack: we're talking about pushftp.
[09:19] <ddaa> Import branches are all important.
[09:20] <ddaa> Ideally, we could guess a likely landing target and put the merged branches away once they are merged.
[09:20] <ddaa> (and if they have no description)
[09:21] <jblack> I suppose with good seperation hiding isn't strictly necessary.
[09:21] <ddaa> Let's clarify assumptions:
[09:21] <jblack> But imagine looking at Aaron's page. He could easily have hundreds of branches a year from now, of which ony 10 may still be pertinant.
[09:22] <jblack> Sure. 
[09:22] <ddaa> I think it would be very sexy to have stuff publicly visible once pushed. It can give a nice "here's what is going on in the bazaar" view of a product.
[09:23] <jblack> Ok. That's a fair reasoning.
[09:23] <ddaa> to get there we cannot expect people to go out of their way and put descriptions. I expect that 95% of branches will have no description. Just because people do not care.
[09:23] <jblack> Exactly.
[09:24] <jblack> And for me personally, that would reduce the value of the 5% that were described. I would be less likely to look at somebody's branch page, knowing that 95% of that cruft is unidentifiable stuff.
[09:24] <jblack> To be clear, I'm not arguing a community consensus. That's strictly my own opinion.
[09:25] <ddaa> Sure. But I think it's reasonable to assume that, for a given person, described branches are likely the few important ones.
[09:25] <ddaa> Your opinion is important.
[09:25] <ddaa> But thanks for clarifying.
[09:26] <jblack> But no, its not a requirement.
[09:26] <ddaa> I'd like to get something real simple and with as few restrictions as possible at first, and get the bzr folks to use it.
[09:26] <jblack> Its a preference issue
[09:26] <ddaa> Then we can have real user feedback.
[09:26] <niemeyer> jblack: Wouldn't you like to know that there's a branch of bzr called bzr.wowfeature by mpool?
[09:26] <jblack> I would like to make a more general point.
[09:26] <ddaa> however, the way branches are currently listed is almost certainly not right.
[09:27] <mdz> carlos: around?
[09:27] <SteveA> ddaa: you're approved
[09:27] <carlos> mdz, yes
[09:27] <jblack> niemeyer: Not if he hadn't cared about it enough to approve it, no.
[09:27] <ddaa> SteveA: come on, you can do better than that!
[09:27] <carlos> mdz, hi
[09:27] <jblack> wowfeature could not be complete, or could have been a half-baked idea he abandoned.
[09:27] <ddaa> SteveA: maybe I should put some pep8 violations in to make it more interesting? ;)
[09:27] <niemeyer> jblack: He may have approved, but just not cared to get into launchpad and put title/description.
[09:27] <SteveA> ddaa: i made comments
[09:27] <ddaa> ha :)
[09:27] <jblack> If martin meant for wowfeature to be known about by the public, he'd describe why it gets a name like "wowfeature"
[09:28] <ddaa> SteveA: thanks
[09:28] <niemeyer> jblack: He may do that in the mailing list, rather than in launchpad..
[09:28] <jblack> When I say hide, I mean from browsing, not from direct access.
[09:30] <niemeyer> jblack: I understood what you meant.. and I'm just saying that if we give users the chance to create branches without providing title/description like we're doing, most users will not care to get into launchpad just to give it a title and description.
[09:30] <niemeyer> jblack: Even though these branches are interesting for other peopl
[09:30] <niemeyer> e
[09:31] <ddaa> Here's an idea...
[09:31] <jblack> niemeyer: Sure. 
[09:32] <ddaa> A person's branch listing should prominently show the 5 branches that had commits most recently, regardless of the presence of a description.
[09:32] <jblack> But if it displayed undescribed branches by default, if it wren't done well, I probably wouldn't go browsing for branches at launchpad unless I had to.
[09:32] <jblack> The signal-to-noise ratio would be too low for me to have personal use for it.
[09:32] <ddaa> Described branches that are neither MERGED or ABANDONED would be displayed as well, regardless of freshness.
[09:33] <jblack> Yeah, if you have FRESHNESS, thats useful to me.
[09:33] <jblack> automatically hide anything either not FRESH or not described, and I'd be a happy camper indeed
[09:33] <niemeyer> ddaa: Tests for bzrsync are exploding because I'm using getUtility without first calling execute_zcml_for_scripts().
[09:33] <ddaa> Then the less-active and non-described branches could be on a "show other branches" page.
[09:33] <niemeyer> ddaa: Any standard way to fix it?
[09:34] <jblack> ddaa: Sure, with checkboxes to hide/show undescribed, hide/show merged. 
[09:34] <ddaa> jblack: I'm not thinking of setting an explicit freshness, just computing it from the metadata in the db.
[09:34] <jblack> I'd have a lot of uses for that.
[09:35] <ddaa> niemeyer: I've been told to look at dyson for that.
[09:35] <jblack> However the backend figures out freshness... <shrug> same difference to me as the likely first enduser. =)
[09:35] <niemeyer> jblack: If the "signal" is too low, having no noise doesn't help. ;)
[09:35] <ddaa> ha, right, you mean as end user, I though you meant as developer.
[09:36] <ddaa> jblack: now, an interesting problem, is can we guess a likely landing target for automatic hiding of merged branches?
[09:36] <niemeyer> jblack: I have no idea about what would be the right way to do it, for sure. But I wouldn't care about hidding branches before it actually becomes a problem.
[09:36] <jblack> niemeyer: Yes, but displaying garbage just because you don't have enough non-garbage doesn't turn the garbage into non-garbage, no? 
[09:37] <ddaa> well, let's just show the lesser garbage :)
[09:37] <ddaa> garbageness is relative, you know
[09:37] <jblack> I agree.
[09:37] <jblack> So, how fresh is fresh? I think a month
[09:37] <ddaa> Ha... that way...
[09:38] <niemeyer> jblack: Whatever..
[09:38] <jblack> a branch with no description and a month with no commits is probably not valuable to me.
[09:38] <ddaa> I think it's better to to show a fixed absolute number of branches.
[09:38] <jblack> and people should be able to mark branches stale too.
[09:38] <jblack> I don't agree.
[09:38] <jblack> Here's why: That makes somebody that works very fast difficult to track.
[09:39] <jblack> That also makes the garbage ratio go up for sporadic developers.
[09:39] <jblack> I think it should be time based.
[09:40] <jblack> for example, I get to work on about half a dozen branches a month for work.
[09:40] <niemeyer> ddaa: Dyson doesn't seem to have anything interesting..
[09:40] <jblack> aaron probably does many multiples of that.
[09:40] <niemeyer> SteveA: Do you know anything about that issue?
 ddaa: Tests for bzrsync are exploding because I'm using getUtility without first calling execute_zcml_for_scripts().
[09:40] <jblack> So a dozen things on aaron's list would only list the last 3 days of his activity. 
[09:41] <jblack> but a dozen things on my list would show the last two months of mine.
[09:41] <ddaa> Two things... 1. fixed number is not a problem for sporadic if it's low enough to glance at (less than 10), and date limit will cause the page to go empty with only a stupid "more branch" link
[09:41] <niemeyer> SteveA: Any standard way to fix it, besides calling the zcml loader on constructor, which could potentially break the test when used as a suite from somewhere else?
[09:42] <ddaa> 2. very active... mh... maybe time limit would be better for those, as there can be many (say up to twenty) interesting branches for a person.
[09:42] <ddaa> jblack: so, I'd suggest the initial listing should show max(fixed number, commited in last month)
[09:42] <SteveA> um... don't use getUtility without first calling execute_zcml_for_scripts().
[09:42] <SteveA> it is the zcml that registers the utilities#
[09:42] <ddaa> jblack: how does that sound?
[09:43] <niemeyer> jblack: A branch with 10 commits per-day which is just merging from mpool is not really interesting.. measurement of branch interest rate is a non-trivial task, IMO.
[09:43] <jblack> niemeyer: it is to me. It tells me which branches to track for activity. :) 
[09:43] <niemeyer> SteveA: Yes, that part is already implied in the above comment :)
[09:43] <jblack> It also tells me which branch to branch off of. :)
[09:43] <SteveA> any test that needs to use getUtility is by definition not a unit test.  it is a functional test.  so it needs a functional test set-up.
[09:43] <SteveA> in the latest zope3 test runner, there's the concept of 'layers' to deal with this kind of requirement.
[09:43] <SteveA> meanwhile...
[09:43] <jblack> but still, I did mention the ability to mark something stale, right? 
[09:44] <ddaa> niemeyer: it would not be very difficult to measure the amount of real new stuff on a branch, but it would be CPU intensive.
[09:44] <SteveA> if it doesn't already, execute_zcml_for_scripts() should have a flag to ensure it is run only once per process.
[09:44] <niemeyer> SteveA: The getUtility is not being used in the test, but inside the BzrSync class.
[09:44] <SteveA> right
[09:44] <niemeyer> (if it matters at all)
[09:44] <SteveA> so, it is a functional test
[09:44] <SteveA> so, either...
[09:44] <jblack> ddaa: I think that your solution is basically right. Automatically decide what stuff is stale, and give the user to override on a per branch basis any individual one. 
[09:44] <SteveA> treat it as a (potentially) full system functional test
[09:45] <SteveA> and run zcml for scripts
[09:45] <SteveA> OR
[09:45] <SteveA> treat it as a slightly larger unit test
[09:45] <SteveA> and register the appropriate utilities in the unit test
[09:45] <SteveA> as stubs
[09:45] <carlos> SteveA, tomorrow morning I will be offline to do some legal papers things. I will be back before the meeting and will have my phone with me just in case someone needs something from me
[09:45] <ddaa> jblack: i'm not sure how I'm going to make that fit with the existing lifecycle-centred listing... but I'll try to come up with something.
[09:46] <SteveA> carlos: okay.  will you be around after the meeting?
[09:46] <ddaa> jblack: in the short term, we need to agree on whether we want to hide auto-registered branches with no description...
[09:46] <carlos> SteveA, yes, I will work as usual when I'm back
[09:46] <jblack> ddaa: This particular approach doesn't have to be the one. But please, please, don't make me sift through 9838383 of aaron's branch to find the one that I want. :) 
[09:46] <niemeyer> SteveA: Ouch.. this is getting too complex.
[09:47] <niemeyer> SteveA: Everything needed is getting the admin user..
[09:47] <SteveA> what is the BzrSync class?
[09:47] <SteveA> is it a database class?
[09:47] <niemeyer>     """
[09:47] <niemeyer>     The purpose of this class is to import data from a bzr branch
[09:47] <niemeyer>     into the Launchpad database.
[09:47] <niemeyer>     """
[09:47] <niemeyer> No, it's a "loader"
[09:48] <ddaa> jblack: related question, should the person pushing a branch to sftp be assumed the author of the branch?
[09:48] <niemeyer> !?
[09:48] <SteveA> so, this class needs to use something
[09:48] <SteveA> something that appears like a part of the database
[09:49] <SteveA>     """The purpose of this class is to import data from a bzr branch into the Launchpad database."""
[09:49] <SteveA> except that's rather a long line
[09:49] <SteveA> so...
[09:49] <SteveA> options are:
[09:49] <SteveA> 1. use the real database
[09:49] <ddaa> niemeyer: first paragraph of a docstring should be a single line. And fit in the 79 cols constraint.
[09:49] <SteveA> 2. use something that provides the API that BzrSync needs
[09:49] <SteveA> the former is a full-system test.  the latter, a unit test
[09:50] <SteveA> the plug-point is getUtility().  That's one of the things getUtility() is for.
[09:50] <ddaa> jblack: ping?
[09:50] <SteveA> So, you need to choose whether to write a full-system test, or a unit test.  If you want the full system test, you need to pay the price in setting up the utilities using zcml.
[09:50] <jblack> ddaa: sorry. Talking to somone on #bzr as well
[09:51] <SteveA> If you want a unit test, you need to add the appropriate stub.
[09:51] <SteveA> to isolate this unit from the rest of the system.
[09:51] <jblack> ddaa: Hmmm.
[09:51] <jblack> ddaa: They're the author after the first commit. prior to that, its just a mirror.
[09:51] <jblack> They're the owner of the branch, though.
[09:51] <SteveA> (so i'll have no excuse next week...)
[09:52] <ddaa> jblack: okay, then we won't auto-set author.
[09:52] <jblack> the concept of author in the bzr context is a rather shaky concept, imho.
[09:52] <ddaa> jblack: agreed
[09:52] <jblack> A revision certainly has an owner though
[09:52] <ddaa> nope
[09:52] <ddaa> don't!
[09:52] <ddaa> A revision has a committer
[09:52] <ddaa> which may or may not be an email launchpad knows about.
[09:53] <ddaa> and may have signatures
[09:53] <jblack> Fair enough.
[09:53] <jblack> a revision has a committer, which to me is synonymous with author.
[09:53] <jblack> a branch is a collection of revisions, which independantly have auth^wcommitters
[09:54] <ddaa> owner/author is something very specific in launchpad, that's why you should avoid conflating terms. I'm happy we talked sabdfl out of Revision.owner.
[09:54] <jblack> I suppose you could argue that the person that assembles revisions is an author of a sort, in that "he assembles" the individual works.
[09:55] <jblack> I can imagine why the two definitions need to remain discrete. Author it is
[09:55] <ddaa> So, the "related branches" and "registered branches" listing could have, at first, an additional section with non-described branches (which should all have lifecycle=NEW), listed in a compact way.
[09:56] <ddaa> jblack: well, there's Branch.author now, IMO it's a bug because we do not have the ability to transfer ownership yet.
[09:56] <jblack> sure, though I'm not sure what the value is of browsing a marked up directory listing in which the only apparent difference is the part after the last / for the branch location.
[09:56] <SteveA> niemeyer: from zope.app.tests import ztapi; from zope.app.tests.placeslesssetup import setUp, tearDown; setUp(); ztapi.provideUtility(IWhatever, object_that_provides_IWhatever, '')  ; tearDown()
[09:57] <ddaa> jblack: at first, because described branches will appear differently.
[09:57] <SteveA> niemeyer: for examples, see sourcecode/zope/src/zope/app/container/browser/tests/test_adding.py
[09:57] <ddaa> jblack: later, because I'll add a freshness feature.
[09:57] <niemeyer> SteveA: Thanks, I was looking for that
[09:57] <ddaa> jblack: then, there's the listing for a product...
[09:58] <jblack> That's where BAV comes in.
[09:58] <jblack> I think that its solvable with some sort of karma measurement on a per-project basis, but does that exist? 
[10:01] <niemeyer> SteveA: Looking at the implementation, the word "boilerplate" suddenly comes into my mind. :-)
[10:01] <niemeyer> ... implementation of LaunchpadCelebrities ...
[10:05] <ddaa> jblack: the definition of "activity" in that spec seems missing.
[10:06] <jblack> ddaa: It defines how to measure activity, but not what activity is? 
[10:06] <ddaa> number of commits, number of commiters etc. is irrelevant, as it's preserved by simple branching and pulling.
[10:06] <ddaa> jblack: AFAICT it defines neither.
[10:07] <jblack> It is a pretty old spec. It may predate bzr
[10:07] <ddaa> Yeah... absolutely...
[10:07] <ddaa> it has one or two interesting items though...
[10:07] <ddaa> It's suggesting the use of a ProductBranchRelationship
[10:08] <ddaa> (anointment of branch by product owners)
[10:08] <ddaa> otherwise, it's mostly wishful thinking and handwaving AFAICT
[10:10] <SteveA> niemeyer: yes.  although, if you derive your test case class from the right thing, you don't need the boilerplate.
[10:11] <SteveA> although, you still need to hook up your chosen object to be that utility.
[10:12] <SteveA> ah... implementation of the celebs.  yeah, that could be made less repetitive.  hasn't seemed worth the effort so far.
[10:13] <niemeyer> SteveA: Yes, that's what I meant.. but anyway, no big deal.
[10:13] <SteveA> niemeyer: be my guest if it irritates you enough to refactor it ;-)
[10:13] <SteveA> or, file a bug on the infrastructure team
[10:14] <SteveA> lines of repetition saved are fewer lines to maintain, after all
[10:14] <niemeyer> SteveA: Thanks. Let's see how many times I'll stumble on it.. :)
[10:15] <SteveA> hmm... we could have a standard unit-testing thing
[10:15] <SteveA> that makes it easy to plug in alternative implementations of various utilities that we expect to be replaced for unit testing
[10:16] <SteveA> without actually having to do the provide-a-new-utility dance
[10:20] <niemeyer> SteveA: Thanks for your support
[10:21] <niemeyer> ddaa: Tests are passing! Go! Go! Go!
[10:21] <niemeyer> :-)
[10:21] <bradb> BjornT_: ping
[10:24] <carlos> mdz, hmmm, not sure if I missed your question... please, could you repeat it if you send me it already?
[10:24] <mdz> carlos: I wanted to ask about gettext-kde
[10:24] <ddaa> niemeyer: cool, is that pushed?
[10:25] <mdz> carlos: if it's not reasonable to bring the patches forward, what other options do we have?  change the .po files?  change the code?
[10:25] <niemeyer> ddaa: Not yet.. I'll do a "full blown" test (importing something real), and will push it.
[10:25] <ddaa> rad!
[10:25] <carlos> mdz, the main problem with that is that I don't understand the patch at first sight and I don't have the time to study it and port it to the new gettext
[10:25] <ddaa> In the meantime I'll look at Steve's review comments for the pybaz patch (incremental mirror output, remember?)
[10:25] <carlos> mdz, the thing is that KDE 4 will not require that special gettext anymore
[10:27] <carlos> mdz, so perhaps the patch migration is not needed in a year or so
[10:27] <carlos> mdz, if you find someone that has time to port the patches, that's a good solution too
[10:28] <mdz> carlos: is the special gettext needed to support a different .po file format, or different API?
[10:28] <carlos> but there is no other way to add full KDE support (either port the patch to latest gettext or adding gettext-kde), at least that we are aware of...
[10:28] <carlos> mdz, no, the .po file is the same
[10:29] <carlos> mdz, they use the msgid string to add the extra information
[10:29] <carlos> so it's still a valid .po file 
[10:30] <carlos> so instead of having: msgid "foo" you have msgid "_: Some context\nfoo"
[10:32] <carlos> mdz: or for this concrete case, the plural forms, msgid "foo" -> msgid "_n: foo\nfoos"
[10:33] <mdz> carlos: ok, so it's a change in how gettext interprets the po file
[10:33] <carlos> mdz, no, it's a change in how gettext extracts the strings from the source code
[10:34] <mdz> hmm
[10:34] <carlos> gettext returns the string as usual, without chanes and KDE then parses it to get the plural forms
[10:34] <mdz> carlos: so the reason to package it separately is for the benefit of rosetta?
[10:34] <carlos> s/chanes/changes/
[10:34] <carlos> mdz, yes
[10:34] <mdz> carlos: ok, thanks
[10:34] <carlos> mdz, to be able to handle KDE translations with Rosetta
[10:35] <elmo> jamesh: !
[10:35] <carlos> mdz, because the .pot generation is done on build time
[10:39] <niemeyer> ddaa: Tested. Preparing to push
[10:40] <lifeless> morning y'all
[10:40] <gneuman> mornig
[10:42] <niemeyer> Morning Robert!
[10:42] <cprov> lifeless: morning 
[10:43] <lifeless> how are you cprov, niemeyer ?
[10:44] <niemeyer> Everything aligned.. :)
[10:45] <cprov> lifeless: I'm fine, recovering slowly from UBZ :) and you ?
[10:46] <lifeless> jetlagged :P otherwise just dandy :)
[10:48] <niemeyer> Oh my! THere are huge ice stones being thrown in the window..
[10:48] <lifeless> ?
[10:48] <lifeless> hail ?
[10:50] <cprov> lifeless: btw, I think PQM is lost due one of my branches, could you check ,please ?
[10:58] <elmo> jamesh: I've kill -STOP'ed whatever you were doing on macquarie, please ping when you're awake
[11:03] <lifeless> spiv: around ?
[11:03] <lifeless> cprov: its hung in the librarian
[11:03] <lifeless> cprov: I'm going to debug with spiv.
[11:03] <lifeless> may take a bit, but would like to prevent recurrence.
[11:06] <jblack> I think we're going to get drupal into bzr.
[11:06] <jblack> It's not sold, but I have someone who sees the light, and about 4 developers who are sold but don't realize it yet
[11:06] <LarstiQ> jblack: talked to walkah yet?
[11:07] <jblack> Yeah.
[11:07] <jblack> He's interested too
[11:10] <Nafallo> yay! :-)
[11:10] <Nafallo> good for them :-)
[11:12] <jblack> Yup. :) 
[11:14] <ddaa> lifeless: pqm appears hung... the first item in the queue dates from more than 3 hours
[11:14] <ddaa> (and the queue has grown ridiculously large, too)
[11:15] <spiv> lifeless: yeah.
[11:22] <LarstiQ> jblack: nice
[11:32] <lifeless> spiv: the librarian is not responding to kill
[11:32] <lifeless> ddaa: I know, read the scrollback please.
[11:32] <ddaa> ack
[11:32] <lifeless> spiv: what can I do to it to help you correct this ?
[11:33] <spiv> lifeless: can you get a backtrace out of it with gdb + pystack?
[11:33] <lifeless> I dunno
[11:34] <spiv> lifeless: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Misc/gdbinit?rev=1.11&view=auto
[11:35] <spiv> lifeless: Or I guess http://svn.python.org/view/*checkout*/python/trunk/Misc/gdbinit?rev=39492  ;)
[11:37] <lifeless> ok, thats setup
[11:37] <lifeless> gdb attached
[11:37] <spiv> Even a plain bt from gdb may help, but pystack would be better :)
[11:38] <lifeless> pystack
[11:38] <lifeless> No symbol "co" in current context.
[11:38] <lifeless> hmm
[11:38] <spiv> (don't run pystack in a non-main thread though, it seems to crash gdb)
[11:38] <spiv> Just keep going up.
[11:38] <spiv> Until it works.
[11:38] <spiv> I should learn enough gdb-fu one day to make it work better.
[11:38] <lifeless> wheres our pastebin >
[11:39] <spiv> lifeless: https://chinstrap.ubuntu.com/~dsilvers/paste/
[11:40] <lifeless> going up killed the process
[11:40] <lifeless> https://chinstrap.ubuntu.com/~dsilvers/paste/file7511Dq.html
[11:40] <spiv> Whee.
[11:41] <lifeless> still canot pystack
[11:41] <ddaa> goodnight guys
[11:41] <lifeless> its not a python debug build AFAIK
[11:41] <lifeless> does that matter
[11:42] <spiv> lifeless: the python2.4-dbg package is all that's needed...
[11:42] <spiv> I wonder if that's installed.
[11:42] <lifeless> elmo: ping
[11:42] <lifeless> so that has killed it
[11:42] <lifeless> its gone now. but lets get setup for the next one
[11:43] <spiv> (python2.4-dbg includes both a debug build, *and* detached debugging symbols for the normal build)
[11:47] <lifeless> mailed rt
[11:53] <spiv> lifeless: thanks
[11:53] <lifeless> did you land those test runner changes you worked on ?
[11:54] <spiv> Hmm, no, I meant to ask you about that -- I don't have permission to merge into the zope branch.
[11:54] <spiv> They passed review, though.
[11:54] <lifeless> you do now
[11:54] <lifeless> SteveA: ping regarding new zope snapshot.
[11:54] <spiv> Ta :)